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

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 54995
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.That's what I said already.>I don't think your logic holds up today. In fact I think it's flawed.There is no flaw in my reasoning. I already said it's faster today because the internal code was re-written to perform the conversions faster.> >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.This step was the major problem years ago. It doesn't seem to become a problem any more unless your db has a half million records in it or more. But it may still be a problem even with db's having only 100,000 records, depending upon your need for speed.> > 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.I challenge you to run a comparison test with 500,000 records in the db, then we will see just who is correct here. I already know the answer, that's why I posted my previous message. I will retract my claims if you prove me wrong ... :)-- Kenneth Grome-------------------------------------------------------------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.That's what I said already.>I don't think your logic holds up today. In fact I think it's flawed.There is no flaw in my reasoning. I already said it's faster today because the internal code was re-written to perform the conversions faster.> >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.This step was the major problem years ago. It doesn't seem to become a problem any more unless your db has a half million records in it or more. But it may still be a problem even with db's having only 100,000 records, depending upon your need for speed.> > 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.I challenge you to run a comparison test with 500,000 records in the db, then we will see just who is correct here. I already know the answer, that's why I posted my previous message. I will retract my claims if you prove me wrong ... :)-- Kenneth Grome-------------------------------------------------------------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/ Kenneth Grome

DOWNLOAD WEBDNA NOW!

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

2003

Top Articles:

Related Readings: