Re: Storing dates (was: Re: Ticket Ordering Question)

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 54993
interpreted = N
texte = Thanks for your history on how date searches took minutes. If that is truly the case, it was not acceptable. However that is clearly not the case any longer. So in my book, programming ease trumps processor efficiency.I don't think your logic holds up today. In fact I think it's flawed.If you use the "convert dates to integers" method...&ledbDatedatarq=[math]{10/21/2003}[/math]&dbDatetype=numeric>Here's what webdna has to do in this situation:>>1- Convert your formatted date parameter to a number.Still has to do that.>>2- Retrieve the formatted date values from the dbDate field of *every* record in the db.Every value has to be "retrieved" in every search... at least the field you're searching on. There's nothing special about retrieving a date-formatted field or an integer except the few CPU cycles for the extra bytes.>>3- Dynamically convert *every* [dbDate] value to a number, then compare that number to the numeric value of the date in your search parameter.Yeah... a couple of additional CPU cycles here.>>4- Identify and retrieve every record with a numeric date value that is "less than or equal to" the numeric date value of your search parameter, then display the results in the founditems context.You already did the compare in the step above. Are you trying to skew the results? ;-) The time to retrieve the actual record is identical in either case.. bits is bits... granted the date-formatted method has a couple of extra bytes for each record.>Obviously this is a lot more work for webdna than if the dates were stored as numbers in the first place. Obviously? a lot? I don't agree.>Therefore webdna will always perform the search FASTER if the dates are stored as numbers.Agreed.> But you will probably never notice the speed difference when using relatively small db files.Or large ones either. We're not talking about your Father's WebDNA or CPU.~Joe-- _______________________________________________________________ Joseph D'Andrea ~ http://www.west21.com/ ~ JoeDan@West21.com WEST21.com Internet services for the 21st Centurywebhosting ~ co-location ~ wireless access ~ WebCat programming-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Thanks for your history on how date searches took minutes. If that is truly the case, it was not acceptable. However that is clearly not the case any longer. So in my book, programming ease trumps processor efficiency.I don't think your logic holds up today. In fact I think it's flawed.If you use the "convert dates to integers" method...&ledbDatedatarq=[math]{10/21/2003}[/math]&dbDatetype=numeric>Here's what webdna has to do in this situation:>>1- Convert your formatted date parameter to a number.Still has to do that.>>2- Retrieve the formatted date values from the dbDate field of *every* record in the db.Every value has to be "retrieved" in every search... at least the field you're searching on. There's nothing special about retrieving a date-formatted field or an integer except the few CPU cycles for the extra bytes.>>3- Dynamically convert *every* [dbDate] value to a number, then compare that number to the numeric value of the date in your search parameter.Yeah... a couple of additional CPU cycles here.>>4- Identify and retrieve every record with a numeric date value that is "less than or equal to" the numeric date value of your search parameter, then display the results in the founditems context.You already did the compare in the step above. Are you trying to skew the results? ;-) The time to retrieve the actual record is identical in either case.. bits is bits... granted the date-formatted method has a couple of extra bytes for each record.>Obviously this is a lot more work for webdna than if the dates were stored as numbers in the first place. Obviously? a lot? I don't agree.>Therefore webdna will always perform the search FASTER if the dates are stored as numbers.Agreed.> But you will probably never notice the speed difference when using relatively small db files.Or large ones either. We're not talking about your Father's WebDNA or CPU.~Joe-- _______________________________________________________________ Joseph D'Andrea ~ http://www.west21.com/ ~ JoeDan@West21.com WEST21.com Internet services for the 21st Centurywebhosting ~ co-location ~ wireless access ~ WebCat programming-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Joe D'Andrea

DOWNLOAD WEBDNA NOW!

Re: Storing dates (was: Re: Ticket Ordering Question)

2003

Top Articles:

Related Readings: