What mysql table structure to use in this case

Question

Hello,

I need to make the databse structure for a real estate website where users can create properties of many types and with many features related to the property.

The main categories will be: 1. House (subtype apartment, house, loft) 2. Commercial (subtype: hotels, buildings, offices, factory) 3. Terrains (subtype: urban, agricola, industrial, for sports)

All this above can have many features defined, for example an apartment: light, gas, # of rooms, bathrooms, floor number, balcony, and so on, and this features are diferent from one property type to another.

At the moment I have one master table named property containing the basic info like address and price, and three subtables property_house, property_commercial, and property_terrain with as many fields as features a property can have.

Is this structure okay? I need to do the creation and modification of all the property types into one form maybe with 3-4 steps and will differ from one property type to another. Will it be easier if I have just one master table like property and a second property_features where to store the property_id, feature_name, and feature_value? What's best for performance and maintaining? What would you people vote for?

Thank you! :)

Answer 1

Well, are these three main categories set in stone? Is there a possibility of a fourth one cropping up in the future? I would probably go with something like this:

CREATE TABLE property (
    id int not null auto_increment,
    name varchar(250) not null,
    property_type int not null,
    property_subtype int not null,
    primary key(id)
);
CREATE TABLE property_type (
    id int not null auto_increment,
    name varchar(250) not null,
    primary key(id)
);
CREATE TABLE property_subtype (
    id int not null auto_increment,
    type int not null,
    name varchar(250) not null,
    primary key(id)
);
CREATE TABLE property_feature (
    id int not null auto_increment,
    property int not null,
    feature int not null,
    value varchar(250) not null,
    primary key(id)
);   
CREATE TABLE property_feature (
    id int not null auto_increment,
    feature int not null,
    value varchar(250) not null,
    primary key(id)
);

I think this would be the most effective in the long run and the most flexible if - when - the time comes.

With this structure, you can then add the data like this:

mysql> INSERT INTO property_type (name) VALUES ('House'),('Commercial'),('Terrains');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> INSERT INTO property_subtype (type, name) VALUES (1, 'Apartment'),(1, 'House'), (1,'Loft');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> INSERT INTO subtype_feature (subtype, name) VALUES (1, 'Light'),(1, 'Floor #');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> INSERT INTO property (name, property_type, property_subtype) VALUES ('Som
e Apartment', 1, 1);
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO property_feature (feature, value) VALUES (1, 'Yes'),(2, '5th');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> INSERT INTO property_feature (property, feature, value) VALUES (1, 1, 'Yes'),(1, 2, '5th');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

You can then get all the features of a particular property pretty easily:

mysql> SELECT s.name, f.value FROM property_feature f INNER JOIN subtype_feature
 s ON f.feature = s.id WHERE f.property = 1;
+---------+-------+
| name    | value |
+---------+-------+
| Light   | Yes   |
| Floor # | 5th   |
+---------+-------+
2 rows in set (0.00 sec)

Answer 2

I have experience with both ways you have mentioned. ( I'm co-developer of iRealty http://www.irealtysoft.com/ ver 3. and ver 4 have two different storage methods). After several years of dealing with both ways I recommend to create a single table for all properties. This pattern is called Single Table Inheritance (http://martinfowler.com/eaaCatalog/singleTableInheritance.html by Martin Fowler).

I see only two disadvantages of this method:

1. field names should be unique within all property types
2. a lot of records will have NULL in about a have of their columns which wastes disk space a little bit

A the same time with this database structure all CRUD routines are very simple and straightforward. You will save a lot of time building queries/ORM layer. With this structure you are free to create indexes and utilize arithmetic and other database functions in WHERE clauses and avoid costly JOINs.

The disk space is cheap, the development time is expensive.

The | property_id | feature_name | feature_value | allows to keep the same database structure when changing fields and property types, which is good when you have a complex upgrade/update routines. If you are going to build a single (production) instance application the upgrades should not be an issue. However this method make CRUD model complex and hence more expensive and bug-prone. (More code --- more bugs.)