Какая структура таблицы mysql для использования в этом случае

Question

Мне нужно создать структуру базы данных для сайта недвижимости, где пользователи могут создавать свойства многих типов и со многими функциями, связанными с этим свойством.

Основные категории будут: 1. Дом (подтип квартира, дом, чердак) 2. Коммерческие (подтип: гостиницы, здания, офисы, фабрики) 3. Terrains (подтип: городской, Agricola, промышленные, для спортивных состязаний)

Все это выше может иметь множество функций, например, квартиру: свет, газ, количество комнат, ванных комнат, номер этажа, балкон и т. д., и эти функции отличаются от одного типа имущества до другой.

На данный момент у меня есть один мастер-таблицу с именем property, содержащий основную информацию, как адрес и цены, а также три подтаблицы property_house, property_commercial и property_terrain с таким количеством полей, имеется свойство может иметь.

Эта структура в порядке? Мне нужно сделать создание и изменение всех типов свойств в одну форму, возможно, с 3-4 шагами и будет отличаться от одного типа свойства к другому. Будет ли проще, если у меня есть только одна главная таблица, такая как property и вторая property_features где хранить свойства_ид, имя_функции и feature_value? Что лучше для производительности и обслуживания? За что бы вы проголосовали?

Спасибо! :)

Answer 1

Ну, эти три основные категории установлены в камне? Возможно ли, что в будущем появится четвертый? Я бы, вероятно, пойти с чем-то вроде этого:

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) 
); 

Я думаю, что это будет наиболее эффективным в долгосрочной перспективе и наиболее гибким, если - когда - придет время.

С этой структурой, вы можете добавить данные, как это:

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 

Вы можете получить все особенности конкретного свойства довольно легко:

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

У меня есть опыт с обоими как вы упомянули. (Я являюсь со-разработчиком iRealty http://www.irealtysoft.com/ ver 3. и ver 4 имеют два разных метода хранения). После нескольких лет работы с обоими способами я рекомендую создать единую таблицу для всех свойств. Этот шаблон называется однонаправленным наложением (http://martinfowler.com/eaaCatalog/singleTableInheritance.html by Martin Fowler).

Я вижу только два недостатка этого метода:

1. имена полей должны быть уникальными в пределах всех видов собственности
2. много записей будет иметь значение NULL в около иметь их колонн, растрачивает дискового пространства, который немного

В то же время с этой структурой базы данных все процедуры CRUD очень просты и понятны. Вы сэкономите много времени на построение запросов/уровень ORM. С помощью этой структуры вы можете создавать индексы и использовать арифметические и другие функции базы данных в предложениях WHERE и избегать дорогостоящих JOIN.

Место на диске дешево, время разработки дорогое.

The | property_id | feature_name | feature_value | позволяет сохранить одну и ту же структуру базы данных при изменении полей и типов свойств, что хорошо, когда у вас есть сложные процедуры обновления/обновления. Если вы собираетесь создать одно (производственное) приложение экземпляра, обновления не должны быть проблемой. Однако этот метод делает модель CRUD сложной и, следовательно, более дорогой и подверженной ошибкам. (Больше кода --- больше ошибок.)