Структура БД для базы недвижимости?

Question

[nllm]

Как лучше организовать таблички для базы объектов недвижимости?

Comments

[nllm]

Для каждого типа недвижимости создать свою табличку?
Создать табличку с общими полями для всех типов, а остальные поля вынести во вспомогательные поля? (тогда быстрый поиск будет по основной таблице, а расширенный сначала по основной, далее по соответсвующей вспомогательно).

[miwa]

Слишком мало входных данных. Какая СУБД будет обслуживать эту базу? Сколько одновременных _активных_ подключений планируется? Доступ из веба, или из интранета?
А вообще я бы для начала пошел к людям, которые не знают, что такое компьютер, но знают, что такое недвижимость. И распросил их как можно детальнее (насколько хватило бы _ихнего_ терпения) о их работе. После чего долго бы рисовал всякое на бумажках. И только после этого думал бы о базах и табличках.

[nllm]

Интересен практический опыт решения подобных задач.
С риэлторами уже все обговорено, бумажки исписаны.

Answer 1

[sl_bug]

Тут посмотрите. Real Estate вас интересует. Может что-нибудь поможет.

Answer 2

[vinxru]

Если вам будет нужно выводить общий список недвижимости, сортировать этот список, выполнять по нему выборку, то делить данные на несколько таблиц не стоит. Скорость поиска упадет во столько раз, на сколько таблиц вы поделили данные (условно).

Время поиска в одной таблице log(n). Время поиска в 8 таблицах в которых записей по меньше = 8*log(n/8).

Можно еще рассмотреть вариант создать единственную таблицу с множеством полей. Поля которые не имеют смысла, просто заполнять NULL.

Comments

[BearOff]

А можно ссылки насчёт сложности поиска в одной таблице и в нескольких? Мне кажется, это какие-то вообще сферические числа, бред даже.

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

[vinxru]

Во первых, утверждение «Всё в одну таблицу» относилось лишь
к списку недвижимости. Помещать в эту таблицу что то кроме
недвижимости не надо :)

…

Приведу ссылку с Хабра же.

«B-tree Операция поиска выполняется за время O(t logt n), где t –
минимальная степень. Важно здесь, что дисковых операций мы
совершаем всего лишь O(log t n)!»

habrahabr.ru/blogs/algorithm/114154/

Логарифм значит, что при при увеличении базы данных в 2 раза,
время поиска возрасает лишь на одну операцию сравнения
(или дисковую операцию, хотя это не всегда так).

Вот и получается, что бы найти нужную запись среди 1.000.000 записей
тратится 0.1 сек. А среди 2.000.000 записей (в одной таблице)
тратится 0.101 сек.

Если мы будем искать в двух таблицах по 1.000.000 записей, то соответсвенно
у нас уйдет 0.2 сек.

…

Или давайте я приведу человечесский пример. У вас есть бумажный телефонный
справочник Москвы, в котором все фамилии упорядочены. Я прошу найти вас человека
с определенной фамилией. Правда ведь это просто? ВЫ открываете по середине
справоника, смотрите букву, затем открываете на середине одной из половин…
И так, уменьшая количество страниц каждый раз в раза раза, вы доберетеь до имени.

1000, 500, 250, 125, 65, 33, 17, 8, 4, 2, 1

Итого 1000 страниц за 11 подходов.

А потом, я даю вам 20 телефонных справоников городов в 20 раз меньше и
прошу найти человека.

50, 25, 12, 6, 3, 2, 1

Итого 50 страниц за 7 подходов. А так как у нас 20 справочников, то всего
будет 140 подходов. Это более чем в 10 раз больше!

…

Вам нужны результаты реальных тестов?

[vinxru]

Завтра за компьютеров вряд ли сидеть буду. Вот детально расписанный эксперимент:

vinxru.livejournal.com/46842.html

[nllm]

Вывода общего списка объектов недвижимости не будет.

[BearOff]

vinxru, спасибо за развёрнутый ответ.
Вы правы, потенциально «Скорость поиска упадет во столько раз, на сколько таблиц вы поделили данные (условно)».
Но это будет в том случае, если все таблицы будут одинакового размера (вы описываете раделение одной большой таблицы на 8 маленьких), и если искать мы будем по индексам. Но на самом-то деле разделение таблиц происходит не по количеству записей, а по их содержимому и отношениям между данными, да и далеко не все столбцы нужно индексировать.
Т.е. основная таблица с недвижимостью, хоть с множеством столбцов, хоть с пятью, будет одного и того же размера — n. А вот все дублирующиеся данные не нужно размещать в этой же большой таблице.

Например, у нас есть в базе несколько типов домов:

Чешки (9 этажей, панельные, с грузовым лифтом)
Чешки (12 этажей, панельные, с грузовым лифтом)
Чешки (9 этажей, кирпичные, с грузовым лифтом)

Если вы разместите эти данные в основной таблице, они, во-первых, займут 4 столбца («чешка», 9, «кирпич», «да»).
Во-вторых, чтобы быстро искать по ним, вам надо будет создать дополнительные индексы.

Я бы сделал по-другому: создал отдельную таблицу «тип дома», которая бы содержала бы эти типы, и была бы очень маленькой. В основной же таблице добавилась бы всего одна колонка — тип дома.

Честно говоря, не могу утверждать, что поиск во втором варианте «кирпичного девятиэтажного дома с лифтом, чешка» будет быстрее, чем в первом (с индексами), но как минимум вы выиграете на размерах базы и на удобстве работы с ней.

Я думаю, лично вы всё это прекрасно понимаете, но просто совет в первом комментарии может быть воспринят неопытным человеком совершенно в лоб: любые дополнительные таблицы всегда уменьшают скорость работы, складываем всё-всё в одну.
При этом вряд ли неопытный человек будет учитывать, что сложность поиска log(n) относится к поиску по индексу. Ну и другие нюансы.

[vinxru]

любые дополнительные таблицы всегда уменьшают скорость работы, складываем всё-всё в одну.

Согласен. Исправлю на «любой дополнительный JOIN или запрос всегда уменьшает скорость работы.».
Я поклоняюсь Нормальной форме, как и многие тут. Но я давно понял, что есть три крайности: Производительность, Простота и Нормальная форма, между которыми приходится выбирать.

[vinxru]

приходится выбирать компромисс.

[BearOff]

Я бы просто поостерёгся давать неопытному человеку совет складывать всё в одну таблицу. Потому что потери на join таблиц будут не настолько ощутимы, чтобы жертвовать удобством поддержки базы.
Как вы сами говорите, следует искать компромисс и не ударяться в крайности.

[vinxru]

А в чем неудобство? Мне очень интересно.

[BearOff]

Простите, но я уже упоминал об этом в комментариях, и даже привл пример (про типы домов).

Причины, по котором данные помещают в разные таблицы, мне кажутся слишком общеизвестными и общепринятыми, чтобы их сейчас обсуждать. Особенно учитывая, что вы, кажется, с подозрением относитесь к нормализации («Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.»).

Вот, например, первое, что нашлось по запросу «построение баз данных».

Поэтому прошу меня извинить — я не буду продолжать дальше разговор. Автор вопроса вроде бы получил ответ на вопрос, и вряд ли продолжение нашей беседы ему поможет.

Спасибо за развёрнутое объяснение о b-деревьях, я давно о них не вспоминал.

Answer 3

[Максим Дьяченко]

Постановка задачи слишком размыта.
Вполне может оказаться, что в Вашем случае лучшим будет даже EAV.
Вообще общий подход — составляем несколько списков полей для разных видов данных.
Потом находим общие поля, пытаемся максимально объединить.
Имеем некий «родительский класс» и некий набор расширений.
Далее что у нас в каждом поле лежит? Не целесообразно ли из этого сделать справочник? (например сотрудники, районы, виды недвижимости и т.п.). На самом деле вопрос не очевидный. Иногда проще сделать перечисление или текстовое поле.
Некоторые поля из разных «классов» можно хранить в одном и том же поле базы если это не противоречит логике поиска (К примеру название поставщика или его ФИО в случае Юрлица или Физлица как правило является одним полем).
Когда мы получаем некий каркас надо трезво посмотреть на этот ужас и ответить — а все ли они нам нужны?
Если по полю не будет поиска или сортировки, то возможно стоит несколько таких полей объединить в одно поле «описание» которое заполняется по шаблону при вводе, или содержит сериализованный массив.

Часто целесообразно общую часть данных вынести в общую таблицу, а для каждого «класса» сделать отдельную таблицу со ссылкой на главную. Типа «объекты недвижимости, подробности квартир, подробности домов, подробности участков земли».

Comments

[nllm]

Спасибо, Ваш вариант приближен к моим видениям.

Answer 4

[phasma]

Руками. Недвижимость настолько разная, что у тебя может быть площадь под ресторан, а может быть склад и у них характеристики очень сильно отличаются. Где-то два дня в итоге потратили на то, что бы расписать структуру БД. Хотя если у тебя будет просто сайтик, то может быть этого и не нужно, в первый раз у меня было полей 8, но там чисто дома и участки. Второй раз я уже писал что-то вроде CRM с кучей ништяков.

Answer 5

[phasma]

Для вывода можно использовать memcached/sphinx/etc

Answer 6

[5erg]

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

Answer 7

[afiskon]

Вот статья по теме, в ней все написано.