Well, OK if that's the interface you want that's fine. It still needn't mean anything re the db design. What I'm trying to say is that the interface and the db design are independent. You can have good db design, and still have simple interface.
You can simply type the ingredient name as you prefer. A query will see if that ingredient exists and use that existing ID, otherwise it will create the ingredient and use the new ID. ----- Original Message ----- From: "Matt Robertson" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Saturday, March 30, 2002 11:30 AM Subject: Re: CF/Database Help > I understand your point but disagree, to a degree ;D. > > I think to your basic gal-on-the-street user the existence of the combo box is a problem and not a solution. Its not just one ingredient. Lets say I have 10 ingredients, and I'm a chef and not a programmer who lives on my computer 12 hours daily. One way, I get to type in the 10 ingredients. I already know and that process intuitively. I'll use that app with minimal training, and understand it. > > The other way, ingredient entry is a series of separate rote processes where I select each item individually from a drop-down list of indeterminate -- but probably LONG -- length, that may have all 10 of them on it... but if it doesn't I have to add the ingredient myself - a separate and non-rote process requiring a mental gear-switch... and what if its already there and I'm too dumb to realize it (remember chili, chilli and Chile)? > > If we go the easy data entry route, then we complicate the programmer's life: how do we search thru all this lumped-together @#$%! > > The answer is ugly: use LIKE (gasp!) > > Its not efficient by any stretch, but in my mind its the only solution compatible with the -- admittedly IMHO -- paramount requirement of usability. > > > --------------------------------------- > Matt Robertson [EMAIL PROTECTED] > MSB Designs, Inc., www.mysecretbase.com > --------------------------------------- > > > ---------- Original Message ---------------------------------- > from: "Matthew Walker" <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > date: Sat, 30 Mar 2002 10:47:37 +1200 > > I think you're right. The biggger the project, the more important is strict > normalisation. On a small system, it might just get in the way. > Nevertheless, you are raising interface issues which are separate from db > design. For example, there's no reason why you couldn't have a combo box > (e.g. cf_combo_box) that let you pick an ingredient or enter a new one. > > ----- Original Message ----- > From: "Matt Robertson" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Saturday, March 30, 2002 10:40 AM > Subject: RE: CF/Database Help > > > > I'm just taking this from the user's side rather than the programmer's. > > > > Would you be making a highly capable system whose elegance is lost on a > user when he has to pick one ingredient from a drop-down list of 200 (and > populate that list himself when he needs a new ingredient not on the list)? > > > > I'm just suggesting that the user should have options put before him: > expandability/capability vs. simplicity/usability, and let him decide. Then > you build based on informed consent. > > > > --------------------------------------- > > Matt Robertson [EMAIL PROTECTED] > > MSB Designs, Inc., www.mysecretbase.com > > --------------------------------------- > > > > > > ---------- Original Message ---------------------------------- > > from: "VAN VLIET, SCOTT E (SBCSI)" <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > date: Fri, 29 Mar 2002 14:12:31 -0800 > > > > I have been raised on a strict background on database normalization. I am > > always thinking of the term, "scalability". ^_^ > > > > -- > > Scott Van Vliet > > Senior Analyst > > SBC Services, Inc. > > ITO Enterprise Tools > > Office: 858.886.3878 > > Pager: 858.536.0070 > > Email: [EMAIL PROTECTED] > > > > > > > > -----Original Message----- > > From: Matt Robertson [mailto:[EMAIL PROTECTED]] > > Sent: Friday, March 29, 2002 2:02 PM > > To: CF-Talk > > Subject: RE: CF/Database Help > > > > > > Is there any particular reason why ONE table wouldn't do the trick just > > fine? > > > > Title (varchar 255) > > Recipe (long text) > > > > or break it out to maybe refine ingredient searches and get a little > > fancier: > > > > ShortDescr (long text) > > Ingredients (long text) > > Method (long text) > > KeyWords (varchar 255) > > > > If all the guy wants to do is type in his recipes and find them again, or > > search for all recipes which contain chili peppers, wouldn't this be > simpler > > for him to maintain and deliver the same functionality? > > > > --------------------------------------- > > Matt Robertson [EMAIL PROTECTED] > > MSB Designs, Inc., www.mysecretbase.com > > --------------------------------------- > > > > > > ---------- Original Message ---------------------------------- > > from: "VAN VLIET, SCOTT E (SBCSI)" <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > date: Fri, 29 Mar 2002 13:49:16 -0800 > > > > Depending on the depth of you database, the best thing to do would to be > > create a master RECIPE table, and a master INGREDIENT table. The, you > could > > create an linkage table that would like n number of ingredients to a > recipe. > > > > EXAMPLE: > > > > RECIPE > > ================================================== > > RC_ID RC_NAME RC_DESCRIPTION > > -------------------------------------------------- > > 10 Chocolate Cookies Yummy! > > 20 Chocolate Brownies More Yummy! > > > > INGREDIENT > > ================================================== > > IN_ID IG_NAME IN_DESCRIPTION > > -------------------------------------------------- > > 1 Flour White Stuff > > 2 Sugar Sweet Stuff > > 3 Egg Yolks & Stuff > > 4 Salt NaCl2 > > 5 Chocolate Good Stuff > > 6 Chocolate Chips Little Stuff > > > > RECIPE_INGREDIENT > > ============================= > > RI_ID RC_ID IN_ID > > ----------------------------- > > 1 10 1 > > 2 10 2 > > 3 10 3 > > 4 10 4 > > 6 10 6 > > 7 20 1 > > 8 20 2 > > 9 20 3 > > 10 20 4 > > 11 20 5 > > > > The table, RECIPE_INGREDIENT, would contain an identity for the > relationship > > (RI_ID), a reference to the recipe (RC_ID) and a reference to the related > > ingredient (IN_ID). > > > > So, to find out what ingredients are used in Chocolate Brownies, you > could: > > > > SELECT RI.IN_ID, IN.IN_NAME, IN.IN_DESCRIPTION > > FROM RECIPE_INGREDIENT RI JOIN > > INGREDIENT IN ON RI.IN_ID = IN.IN_ID > > WHERE RI.RC_ID = 20 > > > > You can go even farther and attach the recipe details to this query. But > I > > hope this leads you in the right direction! > > > > -- > > Scott Van Vliet > > Senior Analyst > > SBC Services, Inc. > > ITO Enterprise Tools > > Office: 858.886.3878 > > Pager: 858.536.0070 > > Email: [EMAIL PROTECTED] > > > > > > -----Original Message----- > > From: Deborah Curley [mailto:[EMAIL PROTECTED]] > > Sent: Friday, March 29, 2002 1:31 PM > > To: CF-Talk > > Subject: CF/Database Help > > > > > > Hi, > > I have a friend whose a chef and has asked me build him a database of > > recipes and a web app he can use to search, enter new recipes, etc. What > I'm > > > > trying to figure out is the best way to store the ingredients since a > recipe > > > > can have anywhere from 5 to 20 ingredients? Any ideas on the best way to > > handle that? > > > > TIA, > > Deb > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > > > > > > > > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
