@Alxxxxnr1

Логическая модель базы данных для портала недвижимости по типу Циана

1.
Есть два типа недвижимости: Жилая и Коммерческая. Но атрибуты у них немного отличаются.

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

Насколько это допустимо или недопустимо вовсе?
Как поступают в таких случаях?


2.
Немного не понимаю когда нужно выносить атрибут в отдельную таблицу?
Например "Тип сделки", может принимать только продажа/аренда, но обычно это хранится в отдельной таблице и используется как внешний ключ.

И если есть какие-то серьезные недопущения прошу указать

P.s. Прошу не пинать, если все совсем плохо

Миниатюры

   

0

@VinniPuh

Alxxxxnr1, По сути, тут нужно всего 2 таблицы фактов
1 Объекты
2 Характеристики (Подчиненная)
и минимум 1 табл. Справочник
3 ТипыХарактеристик.
Можно еще несколько справочников по Адресам, типа:
Регионы
РайоныРегионов
НасПункты
РайоныНасПунктов
Улицы
...
Метро всякие.
Визуально может выглядеть примерно так.
В характеристиках описать любое количество Типов характеристик со значениями.

В зависимости от специфики еще десяток таблиц мохно нагородить, типа
Контрагенты
Телефоны и т.п.
...

Миниатюры

   

1

@index58

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

Кто как. Сколько людей, столько решений.

Когда без этого будет неудобно. А удобство дело субъективное и зависит от того, какой функционал нужно будет реализовывать. То есть, трудно перечислить все случаи, когда это нужно, а когда нет.

Я не вижу недопущений на схемах. Думаю, оба варианта возможны. Всё дело в удобстве. Лично мне, скорее всего, было бы удобнее все объявления хранить в одной таблице с общим набором атрибутов. Но это неточно, т.к. зависит от особенностей проекта.

На первый взгляд, неплохо. Не пинаю

1

@Alxxxxnr1

VinniPuh, Начет справочника по Адресам
Как это хранится в БД? Регионы - РайоныРегионов - НасПункты, это просто строки атрибуты, или внешние ключи, так как я привел во вложении?
Если внешние ключи, как тогда ссылаться на Объект, из каждой таблицы?

Или я не так понимаю..

Миниатюры

 

0

@VinniPuh

Если уж сильно заморачиваться на нормализации БД, то я как то с дури в где то делал так.

Но в зависимости от нужд, можно и так.

Первая схема больше подходит например к БД, типа - Объекты ЖКХ, или там - Выборы, когда вначале вбиваются все данные по жителям и квартирам определенного Места жительства или Избирательного округа. Короче условно полный перечень.
Вторая, типа как у вас БД, где Абсолютно все данные всех объектов не нужны и они добавляются по мере их нужности.

1

@VinniPuh

Добавлю, что в первом варианте вероятность ошибок минимальна, т. к. выбрать можно только то, что введено в справочники, а по второй схеме, обозвать один и тот же например город, можно по разному.
Например:
Москва
Масква
Массква
...
Короче, на любую БД найдется парочка безграмотных и потом поиском можно искать нужное, но не найти или долго во многих вариациях написания.
Моё мнение конечно не абсолютная истина, но после многих лет карпения над БД, пришел к таким выводам и стараюсь их придерживаться по возможности только так.

1