Какую структуру таблицы MySQL использовать в этом случае - PullRequest
2 голосов
/ 01 июня 2009

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

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

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

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

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

Спасибо! :)

Ответы [ 2 ]

2 голосов
/ 01 июня 2009

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

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

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

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

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

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

0 голосов
/ 01 июня 2009

Хорошо, эти три основные категории установлены в камне? Есть ли вероятность появления четвертого в будущем? Я бы, наверное, пошел с чем-то вроде этого:

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)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...