Форум MySQL

Допустим, есть объект со свойствами "1", "2", "3". Другой объект имеет свойства "1", "3", "4". Третий объект имеет свойства "1","2", "4", "5". Так вот вопрос, как правильно с точки зрения оптимизации составить базу данных этих объектов? Сколько должно быть в данном случае таблиц. Ведь объекты имеют как сходные свойства, так и разные.

три
таблица объектов, таблица свойств, таблица наличия свойства у объекта

Хм... если у меня есть три объекта - квартира, коттедж, земельный участок. Для квартиры заполняются поля "Адрес", "Цена", "Кол. комнат",. Для коттеджа - "Адрес", "Цена", "Кол. комнат", "Площадь участка". Для земельного участка - "Адрес", "Цена", "Площадь участка". То есть одна таблица должна содержать поля "Квартира", "Коттедж", "Земельный участок", вторая - "Адрес", "Цена", "Кол. комнат", "Площадь участка". На счет третьей я не понял.

В поиск ходить опять мне?
http://softtime.ru/forum/read.php?id_forum=3&id_theme=36909

Я в поиск заглядываю, когда случай общий, а у меня частный случай.
В той теме два предложенных автором способов - не оптимальные. В первом способе будут повторяться названия полей в каждой таблице, во втором способе будут неиспользуемые поля, поэтому не понимаю, почему вы посоветовали автору второй способ. На счет третьего - предложенного вами - пока изучаю...
Еще вы в той теме употребили такой термин как "нормализованная база". Это какая-такая база?

Нормальная форма БД

ну ответили уже, что спорить-то?
http://ru.wikipedia.org/wiki/Нормальная_форма

и никакой этот случай не частный. любой, кто хотя-бы немного имел дело с БД, сталкивается с такой проблемой. простейшая аналогия: каталог товаров. есть тиблица категорий, есть таблица товаров и есть таблица, их связывающая (связка идёт не по имени, а по уникальным идентификаторам; чаще всего — первичному ключу).

есть такая замечательная книга, с примерами на подобную тему: http://www.ozon.ru/context/detail/id/2631565/?partner=softtimeru

Во-первых, я не спорю. Во-вторых, то что связка идет по первичному ключу - это я и так знаю, и к этой теме это не относится. В-третьих, книга такая у меня есть, но подобных примеров там нет. Так что потрудитесь внимательно читать то, что я описываю в теме.

Может лучше такой вариант
1 таблица (категории)
"Квартира", "Коттедж", "Земельный участок"
2 таблица (данные "Квартира")
"Адрес", "Цена", "Кол. комнат"
3 таблица (данные "Коттедж")
"Адрес", "Цена", "Кол. комнат", "Площадь участка"
4 таблица (данные "Земельный участок")
"Адрес", "Цена", "Площадь участка"
ну и связи 2-3-4 таблиц с id таблицы 1

а если в 1 таблице добавить поле parent_id то можно сделать еще круче :)

id p_id    name 1    0      Квартира 2    0      Коттедж 3    0     Земельный участок 4    0     Дачи 5    1     Однокомнатные 6    1     Двухкомнатные 7    2     Деревянный коттедж 8    3     Участки в мухосранске 9    3     Участки в центре Вашингтона 10  4     Дачи на берегу реки.....

и тд...

Нет.
Именно потому, что БД не в нормальной форме.

Добавление / удаление свойств, не являющихся неотъемлимой частью схемы, не должно приводить к необходимости внесения изменений в структуру БД.

Ваша схема вроде подходит под определение "нормальная форма бд".

vid_nedvijimosti: id| name 1 | квартиры 2 | дома 3 | земля 4 | нежильё options  id| name| unit| type| comment  1 | Адрес |  2 | кол-во комнат |  3 | площадь | кв.м 4 | расстояние до ст.метро | м objects id| id_vid | humman_key 1 | 1 | Твоя квартира 2 | 1 | Моя квартира harakteristiki id | id_obj | id_option | val 1 | 1 | 1 | г. Москва, Измайловский пр.2, 15  2 | 1 | 2 | 3 3 | 1 | 3 | 60  4 | 2 | 1 | г. Санкт-Петербург, Гражданский пр.24, 55  5 | 2 | 2 | 5 6 | 2 | 3 | 80

Только вот хотелось бы спросить, что должно хранится в поле humman_key таблицы objects?

Ключевое (уникальное) название объекта.
Из меня риэлтер никакой. Поэтому не представляю, чем там они свои объекты идентифицируют.
Но врядли ж суррогатным ПК.

А что вы скажете по поводу такой схемы:

Объекты id | тип недвижимости| адрес | цена   |  кол. комнат ----------------------------------------------------- 1  |   квартира      | ...   | ... руб|  3 Коттедж площадь участка | id_объекта -----------------------------------   5 соток       |         1 Зем. участок площадь участка | id_объекта ----------------+------------------   15 соток      |         1

Конечно же свойств объектов намного больше. Но суть в том, что в таблице "Объекты" содержатся общие свойства для всех типов недвижимости, и еще к каждому типу недвижимости отдельную таблицу для свойств, присущих только эти типам (в некоторых случаях не только одному типу недвижимости).

>А что вы скажете по поводу такой схемы:
А что так криво то?

Что именно криво?

>Из меня риэлтер никакой. Поэтому не представляю, чем там они свои объекты идентифицируют.

Там это выглядит вот так.

У меня вопрос по данной схеме: если требуется вывести все объекты недвижимости и их характеристики, то производится сначала запрос к таблице objects, а потом запрос к таблицы harakteristiki. Т.е. общее количество запросов будет равно количеству объектов + 1. Не будет ли это большой нагрузкой на сервер?

>если требуется вывести все объекты недвижимости и их характеристики, то производится сначала запрос к таблице objects, а потом запрос к таблицы harakteristiki.

Не обязательно. Таблицы в запросе можно соединить.

Кстати, у такой структуры, как мне кажется, есть существенный недостаток: значения val всех опций из таблицы options будут одного и того же типа данных.

можно изменить структуру так, чтобы типы оказались разными.

Почему ? вот выдержка из www.microsoft.com/sql

Преобразование логической модели в физическую При переходе от логической модели к физической сущности преобразуются в таблицы,  а атрибуты — в поля (столбцы).  Отношения между сущностями можно преобразовать в таблицы или оставить в виде внешних ключей. В процессе проектирования физической базы данных необходимо соблюдать ряд общих правил: # Каждая таблица должна иметь уникальный идентификатор (первичный ключ). # Все данные таблицы должны относиться к одной сущности. # Желательно избегать атрибутов, способных принимать неопределенные значения. # Таблица не должна содержать повторяющихся полей.

1 таблица (Сущности)"Квартира", "Коттедж", "Земельный участок"

2 таблица (данные "Квартира") "Адрес", "Цена", "Кол. комнат"
3 таблица (данные "Коттедж") "Адрес", "Цена", "Кол. комнат", "Площадь участка"
4 таблица (данные "Земельный участок") "Адрес", "Цена", "Площадь участка"

И как клиент в рамках этой схемы сможет добавить пару тройку офисов, складов, ангаров?

естественно если добавляется новая сущность то под нее создается своя таблица с характеристиками..
но ТС писал Хм... если у меня есть три объекта - квартира, коттедж, земельный участок. те автоматом новая сущность не предусматривалась...

сущности добавляет разработчик, а не клиент.
Клиент добавляет объекты.
Так вот, данная схема не позволяет добавлять такие объекты, потому что отвлеченная сущность "арендуемый объект" в ней не заложена.
А так в принципе, конечно, имеет право.

А что можно сказать про такую структуру базы данных? В чем минусы?
три таблицы:
первая - просто ид объекта
вторая - список всевозможных свойств
третья - значения свойств для конкретного объекта

Object +-------+ |id_obj | +-------+ |   1   | +-------+ Options  +------+---------+ |id_opt| name    |  +------+---------+ |   1  | Адрес   |  |   2  | Площадь |  |   3  | Цена    | +------+---------+ Values +--------+--------+----------------------------------+ | id_obj | id_opt |             value                | +--------+--------+----------------------------------+ |    1   |    1   | г. Москва, Измайловский пр.2, 15 | |    1   |    2   |            100 кв.м.             | |    1   |    3   |            500 000 $             | +--------+--------+----------------------------------+