So...what you're saying is that a "bridge" table is the preferred method of handling many to many relationships...right?
Rick > -----Original Message----- > From: Robertson-Ravo, Neil (RX) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 10:01 AM > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > > PropertType table > Property table > Property + Type Lookup Table > > > > > > > -----Original Message----- > From: Rick Faircloth [mailto:[EMAIL PROTECTED] > Sent: 07 December 2005 15:07 > To: CF-Talk > Subject: RE: SQL Question. Compare one list to another > > 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:226435 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
