i think that'd still be considered a "clean" design to accomplish what you want. if a property record can share more than one property_type, that's the way to do it (IMHO).
On 12/7/05, Ray Champagne <[EMAIL PROTECTED]> wrote: > I'm pretty sure that is what I meant with my "bridge" design. I, like > you, think that's my only choice in this situation. I just hate having > to deal with the two extra tables. This app was very lean and mean, and > this just makes it harder to maintain, IMO. > > I was always taught to avoid bridge (or cross ref) tables, because it > usually meant that you designed your data structure poorly. I > understand that it's unavoidable in some cases, I was hoping that wasn't > the case here. > > Kiley Simpson wrote: > > Can you have the following tables > > > > PROPERTY > > PROP_ID > > PROP_NAME > > > > PROPERTY_TYPES > > PROPERTY_TYPE_ID > > PROPERTY_TYPE_NAME > > > > PROP_TYPE_XREF <- This just has the unique id's from the 2 above tables. > > PROP_ID > > PROPERTY_TYPE_ID > > > > with this you can have unlimited property types per property. > > > > > > At 10:19 PM 12/6/2005, you wrote: > > > >>So - I have a real estate listings table, and my client wants to add a > >>"property type" field to each listing, such as "golf home", "ski home", > >>"village home", "mountain condo" etc to each of the listings. This > >>"field" will then be used in a quick search set of links that will be > >>clickable on each page as an alternative to using the full search > >>capability. The problem I am having is how to add this "field" to the > >>listings table, because a listing can be more than one property type, > >>ie, a "golf home" in the summer is also a "ski home" in the winter, etc. > >> (It's a resort town) Now I think I've got a many to many > >>relationship, and I want out. > >> > >>My first thought was to just input the types into a comma delimited list > >>and store that in a prop_type field in the listings table, but that is > >>just plain ugly to work with, search from, will slow down my pages, etc. > >> > >>I then went to a bridge table design, using a prop_type table with an > >>prop_type_ID and prop_type_name, then using a bridge table to link the > >>three tables together (prop_type_FK, listing_FK, ID) but that'll be a > >>nightmare to maintain in the future. > >> > >>I'm out of ideas. Is there a better way to do what I'm trying to do? > >>Am I stuck? > >> > >>MySQL 4.x DB, BTW. > >> > >>Thanks, > >> > >>Ray > >> > >> > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226382 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
