943,850 Members | Top Members by Rank

Ad:
Feb 14th, 2007
0

Real Estate Properties Databse

Expand Post »
Hi.

I'd like to ask you another question. I read a lot of articles about the topic but I'm still not very sure how to deal with the following problem.

I want to design a database that contains the properties that a real estate agency offers.
The problem is - there are different types of properties - flats, shops, restaurants, hotels, fields...

All these types have some common attributes like location, price, date the property was added, agent that added it, but in the same time all of these types have specific attributes.

I can think of 3 ways to design this database.

1. Use one table for all properties.

for example:
properties (property_id, location, price, date, flat_feature_1, flat_feature_2, shop_feature_1, shop_feature_2, hotel_feature_1...)

This approach seems easy to use but it would introduce a lot of wasted storage since every record will have a lot of NULL values.

2. Use one table for the common properties and separate tables for the different types of properties (shops, hotels, fields...).

for example:
properties (property_id, location, price, date)
flats (property_id, bedrooms, baths, floor...)
shop (property_id, mall_name, equipment...)

3. Use separate tables for the different types of properties.

for example:
flats (flat_id, location, price, date, bedrooms, baths, floor...)
shops (shop_id, location, price, date, mall_name, equipment...)

---


I probably won't chose the first approach. I'd love to know what you think about 2 and 3. Do you think it's a bad idea to have identical fields in different tables like in approach 3?

Thank you very much.
Last edited by M40; Feb 14th, 2007 at 9:48 am.
Similar Threads
M40
Reputation Points: 10
Solved Threads: 0
Newbie Poster
M40 is offline Offline
9 posts
since Jan 2007
Feb 15th, 2007
1

Re: Real Estate Properties Databse

It really depends on how buzy your website is expected to be. In case you are expecting a lot of both read and write transactions for the flats or let's say country houses, you better keep them in a separate table, instead of mixing them with the rest.

How about rentals and sales offered? Are you going to use a marker for sales/rentals/both properties, or you're going to keep them in separate tables?

I would go for the separate table for each property type, which table will hold both for sale and for rent. This way you will have faster searching.

Also - think of a way for removing sold entries from the database once they have been sold. This will boost search as well.

For example...you can remove entries marked sold once a week, moving them to a table called sold. This way users that want to review a sold house will find it easier in the sold database, while active entries will be querried much faster.

Regarding table columns...keep as much as possible the common specs(e.g. size, floor, price, etc. ) using identical structure in all your tables. In this way you will spend less time figuring out how to make the correct querry, without changing a lot of code.

Good luck
Reputation Points: 21
Solved Threads: 26
Posting Whiz in Training
Rhyan is offline Offline
240 posts
since Oct 2006
Feb 18th, 2007
0

Re: Real Estate Properties Databse

Thank you so very much Ryhan. I didn't expect so detailed and friendly reply. Sorry for delaying mine.

I think I would go for separate tables too. I thought about your suggestion for moving the sold entries. I'll probably use this approach for my project.

Thank you very much.
M40
Reputation Points: 10
Solved Threads: 0
Newbie Poster
M40 is offline Offline
9 posts
since Jan 2007

This thread is solved

Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in Database Design Forum Timeline: ER diagram
Next Thread in Database Design Forum Timeline: Suggestions for my db





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC