I am toying with a few different methods of creating a database schema that will hold information about some rental properties the university owns.
My first method was to create a schema that consisted of many tables, one for each attribute, and then relate them to the properties table with FKs. This is my diagram: http://acelinkdev.evansville.edu/Temp/Method1.gif (This leads to many tables, but easy to control referential integrity.) My second method was to create a single 'attributes' table that contained, basically, all the other tables that stored attributes about a house. This is my diagram: http://acelinkdev.evansville.edu/Temp/Method2.gif (Note: Not all attributes were added to the Property table for lack of time.) (This leads to fewer tables, but harder to control referential integrity.) My third method was to add a many-to-many relation between Property and Attributes. (No diagram for this method.) With the third method, would I put *only* the "options" in join table or *all* of them? For example, "street" is not an optional attribute, however, "porch" may be. Can anyone give some suggestions on how best to design this schema? Eventually, we may add the capability to search and filter items based on select boxes or check boxes. Thanks M!ke ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:207672 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
