Re: Is there a max number of fields?
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 19207
interpreted = N
texte = At 10:16 AM 7/29/98 -1000, Ken Grome tapped the keys to say: >>I wanted to ask you guys if there is any limit on the number of fields in >>a database? > >No.Okay, on a somewhat related note then, how do you know when to create one database with many fields OR several databases with a few fields each. I read Peter Ostry's somewhat helpful post Re: autocommit problem, (the *meat* of which is pasted at the end of my problem) BUT I'm not sure which one applies to my situation. I'll try to explain what my client wants and maybe someone with some more experience can point me in the right direction. (It's my first time, be gentle)Client has a database of approx. 6,000 dive gear products in a variety of brands and categories (masks, fins, snorkels, BC's, books, wet-suits, etc.) Client wants a user interface that goes like this: Visitor hits Entry.tpl and is presented with two pull-down menus Search by brand & Search by Category. If Client chooses say, Masks from the Search by Category pull-down menu, it will take them to the Search.tpl where they can further narrow the search by checking boxes of mask brands they're interested in, weather they have a preference for 2 windows or 4 windows, what kind of purge system they'd prefer, and what colors they'd like. After setting their presences and submitting the form, they'd be taken to the Results.tpl that will list all the products that meet the visitor's criteria (sorted by title since the client doesn't want ten of the same product listed just because the SKU is different for each color availability and/or size). Then, a visitor could click, details on one of the products listed to go to the Details.tpl. Here, the visitor will of course see the product image, description, etc. From this page the visitor should be able to choose what size & color the want and add the item of their choice to their shopping cart. Okay, that seems normal enough, right? Here's the catch. In other categories, or even worse, if the visitor choose to search by brand initially, the fields may need to be entirely different. For example, If they choose the brand Blue Reef from the Entry.tpl pull-down menu, then on the Search.tpl It would list all the categories of products that Blue Reef makes and each item would have a pull-down menu to take the user to the Blue Reef product subcategory they choose. Let's say the choose go to the pull-down menu under Dive Computers, and choose the sub-category Metric. (You can see already that my Search.tpl will be TOTALLY different depending on weather or not they click Search by brand or Search by Category.) So now the user get to the results page & sees a list of all the Blue Reef, Metric, Dive Computers (again sorted by title) and they can click on the details link to see more info but NOW instead of showing the # of windows, size, and color info, they are shown weather or not the product is PC download-able, or Nitrox, Hoseless or Air Integrated. [GULP!] As a newbie to WebCatalog, I'm thinking okay, I'll be using a @$%!-load of [showif] commands on my Search, Results, & Details .tpl's. Then I read a post to the list that says using lots of [SHOWIF 1=2][redirect http://www.somepage.com/][/SHOWIF] will slow my server WAY, WAY down. So should I instead make a different database for every category? If so how do I search by brand across all categories?The database I created initial contains the following 24 fields:SKU, TITLE, PRICE, WEIGHT, BRAND, CATAGORY, TYPE1, TYPE2, TYPE3, SIZE, SIZECHART, COLOR, SEX, TEMPRANGE, HASIMAGE, IMAGE, HASLIMAGE, LIMAGE, DESCRIPTION, FEATURES, REPLITEM1, REPLITEM2, OPPADD1, OPPADD2, While every record has info in the SKU, Title, Price, & Weight fields, I've also included 3 subcategory fields (Type 1, 2, & 3), a field for temperature range (since that is something the client wants searchers to be able to specify when looking for wet suits) a field for color (to be used on items where alt. colors are available), 2 replacement items fields (since some item are to be shown on the Detail.tpl as needing additional batteries, bulbs, etc.), & 2 Optional Additional fields because *sometimes* the client wants to suggest related products if a particular item is added to their cart.I know I've probably asked WAY TOO MANY questions in one post but I'm afraid the answers are all inter-dependant. Please forgive me!! To simplify & recap:1. Can I do it all with the one database? & if so: 2. Do I have enough (or the right) fields to do all the different searches I need? 3. Is it possible to use *that many* [showif] tags without ridiculous slow-downs? 4. If it *would* be better to do multiple databases, say one for each brand, how do I do a search calling up all the catagories listed in all the databases?I hope that one of you will be able to make sense of this long message and find it in your busy schedules to give me some advice?100 lbs of thankfulness in advance,Angel J. Bennett ! We want the world and VP / Creative Dir. ! we want it... The WWW Store ! NOW! 818-905-6787 ! http://www.thewwwstore.com >example 1: >You have many fields, but to search in 3 fields only and display lists with >a maximum of 4 fields plus the search fields? Use numbered records, make a >separate database with only record numbers and the 3+4 fields in question. >If one clicks on a list item, you identify it by the record number and show >the detail with a super-fast [lookup...] > >example 2: >You discover, that you have a lot of double keywords to search for: copy >unique keywords into a new database. A simple trick, but with [lookup..] >you instantly know wether it makes sense to do a real search on the >original data. > >example 3: >If one clicks on a list item, you have to make a complicated search in a >huge database to find this record: it was your fault - use unique numbers >to identify the records, do not perform similar searches twice. > >example 4: >Everything is slow because of so many records and ugly searches: think >about splitting the db's - maybe you find some criterion to search just one >of the databases. You can also split them by some common identifiers like >categories and rethink the search system you present the user.
Associated Messages, from the most recent to the oldest:
At 10:16 AM 7/29/98 -1000, Ken Grome tapped the keys to say: >>I wanted to ask you guys if there is any limit on the number of fields in >>a database? > >No.Okay, on a somewhat related note then, how do you know when to create one database with many fields OR several databases with a few fields each. I read Peter Ostry's somewhat helpful post Re: autocommit problem, (the *meat* of which is pasted at the end of my problem) BUT I'm not sure which one applies to my situation. I'll try to explain what my client wants and maybe someone with some more experience can point me in the right direction. (It's my first time, be gentle)Client has a database of approx. 6,000 dive gear products in a variety of brands and categories (masks, fins, snorkels, BC's, books, wet-suits, etc.) Client wants a user interface that goes like this: Visitor hits Entry.tpl and is presented with two pull-down menus Search by brand & Search by Category. If Client chooses say, Masks from the Search by Category pull-down menu, it will take them to the Search.tpl where they can further narrow the search by checking boxes of mask brands they're interested in, weather they have a preference for 2 windows or 4 windows, what kind of purge system they'd prefer, and what colors they'd like. After setting their presences and submitting the form, they'd be taken to the Results.tpl that will list all the products that meet the visitor's criteria (sorted by title since the client doesn't want ten of the same product listed just because the SKU is different for each color availability and/or size). Then, a visitor could click, details on one of the products listed to go to the Details.tpl. Here, the visitor will of course see the product image, description, etc. From this page the visitor should be able to choose what size & color the want and add the item of their choice to their shopping cart. Okay, that seems normal enough, right? Here's the catch. In other categories, or even worse, if the visitor choose to search by brand initially, the fields may need to be entirely different. For example, If they choose the brand Blue Reef from the Entry.tpl pull-down menu, then on the Search.tpl It would list all the categories of products that Blue Reef makes and each item would have a pull-down menu to take the user to the Blue Reef product subcategory they choose. Let's say the choose go to the pull-down menu under Dive Computers, and choose the sub-category Metric. (You can see already that my Search.tpl will be TOTALLY different depending on weather or not they click Search by brand or Search by Category.) So now the user get to the results page & sees a list of all the Blue Reef, Metric, Dive Computers (again sorted by title) and they can click on the details link to see more info but NOW instead of showing the # of windows, size, and color info, they are shown weather or not the product is PC download-able, or Nitrox, Hoseless or Air Integrated. [GULP!] As a newbie to WebCatalog, I'm thinking okay, I'll be using a @$%!-load of
[showif] commands on my Search, Results, & Details .tpl's. Then I read a post to the list that says using lots of [SHOWIF 1=2][redirect http://www.somepage.com/][/SHOWIF] will slow my server WAY, WAY down. So should I instead make a different database for every category? If so how do I search by brand across all categories?The database I created initial contains the following 24 fields:SKU, TITLE, PRICE, WEIGHT, BRAND, CATAGORY, TYPE1, TYPE2, TYPE3, SIZE, SIZECHART, COLOR, SEX, TEMPRANGE, HASIMAGE, IMAGE, HASLIMAGE, LIMAGE, DESCRIPTION, FEATURES, REPLITEM1, REPLITEM2, OPPADD1, OPPADD2, While every record has info in the SKU, Title, Price, & Weight fields, I've also included 3 subcategory fields (Type 1, 2, & 3), a field for temperature range (since that is something the client wants searchers to be able to specify when looking for wet suits) a field for color (to be used on items where alt. colors are available), 2 replacement items fields (since some item are to be shown on the Detail.tpl as needing additional batteries, bulbs, etc.), & 2 Optional Additional fields because *sometimes* the client wants to suggest related products if a particular item is added to their cart.I know I've probably asked WAY TOO MANY questions in one post but I'm afraid the answers are all inter-dependant. Please forgive me!! To simplify & recap:1. Can I do it all with the one database? & if so: 2. Do I have enough (or the right) fields to do all the different searches I need? 3. Is it possible to use *that many*
[showif] tags without ridiculous slow-downs? 4. If it *would* be better to do multiple databases, say one for each brand, how do I do a search calling up all the catagories listed in all the databases?I hope that one of you will be able to make sense of this long message and find it in your busy schedules to give me some advice?100 lbs of thankfulness in advance,Angel J. Bennett ! We want the world and VP / Creative Dir. ! we want it... The WWW Store ! NOW! 818-905-6787 ! http://www.thewwwstore.com >example 1: >You have many fields, but to search in 3 fields only and display lists with >a maximum of 4 fields plus the search fields? Use numbered records, make a >separate database with only record numbers and the 3+4 fields in question. >If one clicks on a list item, you identify it by the record number and show >the detail with a super-fast [lookup...] > >example 2: >You discover, that you have a lot of double keywords to search for: copy >unique keywords into a new database. A simple trick, but with [lookup..] >you instantly know wether it makes sense to do a real search on the >original data. > >example 3: >If one clicks on a list item, you have to make a complicated search in a >huge database to find this record: it was your fault - use unique numbers >to identify the records, do not perform similar searches twice. > >example 4: >Everything is slow because of so many records and ugly searches: think >about splitting the db's - maybe you find some criterion to search just one >of the databases. You can also split them by some common identifiers like >categories and rethink the search system you present the user.
Angel Bennett
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:
Speed Optimization - Mac (1997)
[WebDNA] rules for naming [math] and [text] vars (2008)
Exclude by date - multiple (1997)
Fun with Dates - finally resolved but.... (1997)
E-mail loop ! (1997)
[WebDNA] Send Mail and Outlook Express (2008)
Pass a form (2003)
Major bug report on rootbeer (1997)
WebCat2 several catalogs? (1997)
Almost a there but..bye bye NetCloak (1997)
WCS Newbie question (1997)
Locking up with WebCatalog... (1997)
Explorer 3.0 (1997)
Snippet to calculate local time (2003)
Too Much Rootbeer Free Offer (1997)
Putting & into a database (1999)
Enhancement Request for WebCatalog-NT (1996)
Re(2): Share Bulletin Board? (1998)
[WebDNA] WebDNA app (2013)
Help formatting search results w/ table (1997)