Ok...so...for my own edification... If "bridge" table or whatever the true db term is for them are frowned upon (and on this list I've had people recommend them for many to many relationships), what is the "best practice" to solve an issue where, say, there is a real estate property that is many "property types", such as "golf house" "beach house" "vacation home", etc.
What would be the "best practice" in constructing the db schema? Looking for clarification... Rick > -----Original Message----- > From: Robertson-Ravo, Neil (RX) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 8:27 AM > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > > I agree with Russ here, I don't like it (for the third time) and > I would not > code or approve it in a DB design but I do not see it being bad > design when > the need can or does arise. > > N > > Each to their own I suppose... > > ;-) > > > > > > -----Original Message----- > From: Snake [mailto:[EMAIL PROTECTED] > Sent: 07 December 2005 12:32 > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > I have to disagree, it is a bad database design, but I agree > there is times > when you might need to do it. > Denormalisation is often done when this provides performance increases. > In the below example, it would be much faster to have a list of values > stored in a single column if you only need to read them. If you need to > compare them against other values as is the case here, then it's > a bad idea > as you cannot easily do it and would require all kinds of extra > processing. > > Normalisation comes at a price, which is nearly always performance. IF > normalising a table by creating lookup tables results in HUGE queries and > massive tables, then you need to consider if you really need to do this. > > Russ > > > -----Original Message----- > From: Robertson-Ravo, Neil (RX) > [mailto:[EMAIL PROTECTED] > Sent: 07 December 2005 12:11 > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > I see where you are coming from but honestly, it's a matter of > course - I do > not like it, but it is not "bad database design"; it may not be everyone's > idea of good design but there could be valid reasons to do so. > > Using lists within a DB design does not break any DB design "rules" i.e. > industry standard. > > There are many tricks that we all use which may be regarded as > bad design - > plularised table tables, int datatypes when tinyint should be used, > underscores in table or column names - all of which (depending on who you > speak to) are bad designs. > > > > > > -----Original Message----- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: 07 December 2005 11:52 > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > > It is not ideal; but it is not bad design pe se - there my be reasons > > to store them in this manner in some design cases. > > No, actually, that is a textbook example of bad database design. While you > may have reasons for doing this - I can't think of any offhand, but who > knows? - it would still be bad purely according to the > fundamental tenets of > relational database design. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction > at our training centers in Washington DC, Atlanta, Chicago, Baltimore, > Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more information! > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226417 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
