Re: How is it done?

This WebDNA talk-list message is from

1998

It keeps the original formatting. numero = 17454
interpreted = N
texte = >Also, searching by date can be slow because so>much interpretation is required of mm/dd/yyyy fields. You can get as much>as a 10x improvement on date searches if you reformat them to be>text-sortable as yyyymmdd.I can see where this particular format would make searching faster, but what about re-formatting my dates as the number of days since 1900? Wouldn't that make searching even faster yet?After all, the number of days since 1900 format results in a value that is exactly 6-digits long, at least for the next 700 years or so ... which is far greater a date range than I will ever need.It seems the potential benefits of using this format might include:1- It is 25% smaller than the 8-digit yyyymmdd format you suggested above, so it's more compact and requires less RAM and creates small er database files.2- It is a format that's useful inside the [math] context directly -- as a number -- instead of being a value that must be 'interpreted' by WebCat as a date before it can be added to or subtracted from.This discussion leads me to my next question:You mentioned that storing dates in text-sortable format can yield a 10x improvement on search times. Wouldn't a *numeric* search be even faster than a text-based search? Obviously I can write my search context with these parameters:&group1field=FieldName&group2field=FieldName&grgroup1datarq=[math]{[date]}-7[/math]&legroup2datarq=[math]{[date]}[/math]But wouldn't faster results be obtained by using this code instead?:&rnFieldNamedatarq=[math]{[date]}-7[/math],[math]{[date]}[/math]Provided I'm very careful to make sure the the smallest number in the range appears first, before the comma, so the rn stuff doesn't break?And this brings up another question, one that I asked a few days ago but has not yet been answered:Does using the rn parameter in a search like this require that we also put FieldNameType=num into the search parameters? Or does the rn serve to inform WebCatalog that the values it's comparing are numbers, and therefore make it unnecessary for us to add that FieldNameType=num to the search string?The docs say nothing about adding FieldNameType=num to the search parameters in this situation, and in fact the example in the docs is missing this FieldNameType=num parameter altogether ... so I'm still not sure if it is required or not.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net Associated Messages, from the most recent to the oldest:

Re: How is it done? (Kenneth Grome 1998)
Re: How is it done? (PCS Technical Support 1998)
Re: How is it done? (PCS Technical Support 1998)
Re: How is it done? (Trevor Crist 1998)
Re: How is it done? (Kenneth Grome 1998)
Re: How is it done? (Kenneth Grome 1998)
Re: How is it done? (PCS Technical Support 1998)
Re: How is it done? (Kenneth Grome 1998)
Re: How is it done? (PCS Technical Support 1998)
How is it done? (Kenneth Grome 1998)

>Also, searching by date can be slow because so>much interpretation is required of mm/dd/yyyy fields. You can get as much>as a 10x improvement on date searches if you reformat them to be>text-sortable as yyyymmdd.I can see where this particular format would make searching faster, but what about re-formatting my dates as the number of days since 1900? Wouldn't that make searching even faster yet?After all, the number of days since 1900 format results in a value that is exactly 6-digits long, at least for the next 700 years or so ... which is far greater a date range than I will ever need.It seems the potential benefits of using this format might include:1- It is 25% smaller than the 8-digit yyyymmdd format you suggested above, so it's more compact and requires less RAM and creates small er database files.2- It is a format that's useful inside the [math] context directly -- as a number -- instead of being a value that must be 'interpreted' by WebCat as a date before it can be added to or subtracted from.This discussion leads me to my next question:You mentioned that storing dates in text-sortable format can yield a 10x improvement on search times. Wouldn't a *numeric* search be even faster than a text-based search? Obviously I can write my search context with these parameters:&group1field=FieldName&group2field=FieldName&grgroup1datarq=[math]{[date]}-7[/math]&legroup2datarq=[math]{[date]}[/math]But wouldn't faster results be obtained by using this code instead?:&rnFieldNamedatarq=[math]{[date]}-7[/math],[math]{[date]}[/math]Provided I'm very careful to make sure the the smallest number in the range appears first, before the comma, so the rn stuff doesn't break?And this brings up another question, one that I asked a few days ago but has not yet been answered:Does using the rn parameter in a search like this require that we also put FieldNameType=num into the search parameters? Or does the rn serve to inform WebCatalog that the values it's comparing are numbers, and therefore make it unnecessary for us to add that FieldNameType=num to the search string?The docs say nothing about adding FieldNameType=num to the search parameters in this situation, and in fact the example in the docs is missing this FieldNameType=num parameter altogether ... so I'm still not sure if it is required or not.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net Kenneth Grome

DOWNLOAD WEBDNA NOW!

Re: How is it done?

1998

Top Articles:

Related Readings: