Пытаюсь накидать схему бд для проекта Real Estate(пр. "Циан"). Не могу решить как поступить с данными о недвижимости.
Раскидать по разным таблицам, т.е сколько типов недвиги столько таблиц. Или хранить все в одной таблице?
Ваша первая ошибка в качестве проектировщика схем СУБД.
Число типов класса объекта не должно множить структуру БД.
Любое добавление нового типа должно сопровождаться добавлением записей в базу (должны использоваться только DML), а не новых единиц структуры базы (не должны использоваться DDL).
Everything_is_bad, Есть объявления, у которых есть привязываемый тип недвижимости(пр. квартира, дом, оффис). У каждого типа недвижимости могут пыть какие-то параметры, как общие, так и индивидуальные(пр. площадь для типов "дом"/"квартира", размер участка для типа "дом").
KonstantinDyulin, при поиске, объекты разного типа могу быть в одной выдачи? вообще, чтобы принимать решения при проектировании, нужно сначала ознакомиться с полным ТЗ.
если количество типов этих объектов небольшое, а новые типы не планируется добавлять или их добавление очень-очень редко, то и имеет смысл рассмотреть разбивку на несколько разных таблиц, это при условии что в ТЗ нет других требования из-за которых это станет неэффективным.
Объекты, скорее всего, незачем раскидывать по нескольким таблицам, потому что значительная часть их обработки будет единообразной, и разделение только спровоцирует дублирование кода да усложнение запросов.
Даже если у объектов принципиально разные, не совместимые между собой и при этом строго формализованные параметры - можно сделать несколько таблиц параметров и уже их привязывать к единой таблице объектов.
Параметры-то важны только на витрине и при оформлении покупки, по всему остальному порталу объект - он и есть объект.
Ну, и как выше справедливо заметили, новые данные не должны требовать новых таблиц.
Только - новая логика их обработки.
Простой
