Results 1 to 5 of 5
Jan 26, 2006, 02:52 #1
- Join Date
- Apr 2005
- 0 Post(s)
- 0 Thread(s)
your opinions on my database design
I'm building a database for a holiday rentals site and would really appreciate comments on how best to approach it's design.
At the moment I have tables set up with summary details for each property in order to deal with property searchs like this:
1. prop (summary property details for all properties - the following is just an extract of the columns):
address NOT NULL
bed_no NOT NULL (indexed)
The bed_nomax column records the total number of bedrooms for properties available as separate units (e.g a property split into a 1 bed, 2 bed and 3 bed apartment and you could rent out one or all or any combination - bed_nomax would be 6). This is so a search for a rental property with 6 bedrooms would pick up that property.
2. specialist_id(the different types of holidays that can optionally be searched on eg skiing, golf etc not applicable for a lot of properties):
3. specialist_prop (properties with specific activities - can have more than one activity)
4. restrict_id (restrictions like no smoking etc)
5. restrict_prop (properties with restrictions - can have more than one restriction)
6. multi_units (the following is just an extract of columns and lists all the individual units for multi_unit properties)
bed_m (the bed no for each unit)
I'm now need to create tables to record the detailed information for each property that will be displayed when a property is selected from the search. There would be about 50+ bits of information with things like microwaves, cd players, linen etc along with the blurb about each property.
I'm wandering if I should normalise this and have tables for feature types and feature type by prop_id with the advantage that it would be scalable or just stick to a single table with multiple columns. As it stands if I create a single table for these details, I would be using JOINS to the summary tables to display info for a single property.
I know this question gets asked a lot but the thing is at the moment there are only 150 properties and the projection for 600 max over the next couple of years. With such a small number of rows is it worth splitting the information up into seperate tables?