Re: Summary search -- speed
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 12136
interpreted = N
texte = >The summary search command appears very useful for pulling out unique fields,>such as the categories in the Tea Room example that ships with 2.0.>>I'm wondering what type of speed this summary search command has over large>databases. If the inventory was in the 100K records range, would there be a>significant speed hit for a unique entry summary search?A search on a smaller database is always faster, but it may not benoticeable in WebCat2 because it's already so fast. Maybe the number ifdifferent categories would be the speed-limiting factor in this case, Idon't know. But the fastest solution will be a separate database, that'sfor sure.>Would I be better off>with a separate data table that kept a unique list of categories, etc?Yes, of course, especially since it seems you already have the basicunderstanding that planning is the most important part of creating anextendable WebCat2-based service.>I don't yet have the large inventory database to play with, but I need to plan>ahead for it.If you create a separate database that has all your categories in it, thenyou won't ever have to worry about this again. Write your WebDNA properly,and this technique gives you the added advantage of restricting thecategories entered in the large database to only the ones you havepreviously entered into the smaller 'category.db' file.Popup lists created from a search on your category.db are a great way toimplement this feature ... :)Sincerely, Ken GromeWebDNA Solutions
Associated Messages, from the most recent to the oldest:
>The summary search command appears very useful for pulling out unique fields,>such as the categories in the Tea Room example that ships with 2.0.>>I'm wondering what type of speed this summary search command has over large>databases. If the inventory was in the 100K records range, would there be a>significant speed hit for a unique entry summary search?A search on a smaller database is always faster, but it may not benoticeable in WebCat2 because it's already so fast. Maybe the number ifdifferent categories would be the speed-limiting factor in this case, Idon't know. But the fastest solution will be a separate database, that'sfor sure.>Would I be better off>with a separate data table that kept a unique list of categories, etc?Yes, of course, especially since it seems you already have the basicunderstanding that planning is the most important part of creating anextendable WebCat2-based service.>I don't yet have the large inventory database to play with, but I need to plan>ahead for it.If you create a separate database that has all your categories in it, thenyou won't ever have to worry about this again. Write your WebDNA properly,and this technique gives you the added advantage of restricting thecategories entered in the large database to only the ones you havepreviously entered into the smaller 'category.db' file.Popup lists created from a search on your category.db are a great way toimplement this feature ... :)Sincerely, Ken GromeWebDNA Solutions
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
problems with 2 tags (1997)
Trouble with carts (2000)
Location of Browser Info.txt file (1997)
search form problem.. (1997)
Help! WebCat2 bug (1997)
PCS Frames (1997)
[Fwd: F3 database munching] (1997)
carriage returns in data (1997)
another problem (1997)
Webcat2, WebCommerce, Mod 10 etc. (1997)
success - serial numbers and webmerch (1997)
Brain Fade (2003)
Quick ShowIf question (1997)
Fedora Core 2 (2005)
WebCatalog NT beta 18 problem (1997)
HELP..Changing Price after adding to cart. (1999)
Bad Cookie (1998)
Emailer (WebCat2) (1997)
Nested tags count question (1997)
[WriteFile] problems (1997)