Как проектируются БД для таких сайтов?

Question

[Jony1337]

Допустим есть сайт по продаж квартир . Там у каждой квартиры есть куча инфы которую нужно хранить в БД , ну и сам вопрос , как её правильно хранить , я сделал вот так prntscr.com/e4fvbp . Но думал хранить всё в json массиве тоже в БД до зато не нужно создавать по 10 полей для каждой характеристике .
Может я что то не так делаю или учил старый материал ?
Может есть более осовремененный подход в 2017 году к этой задачи ?

Comments

[DevMan]

Джони, забудь о теге пхп.

Answer 1

[ThunderCat]

Как проектируются БД для таких сайтов?

1) Четкие названия для каждого поля, на английском (это стандарт, не ленитесь заглянуть в гугл транслейт для перевода, и сами английский подтянете, и выглядит профессионально, за код не стыдно и тд)
2) В полях где можно сделать ограниченное количество вариантов ставится поле типа int и к этому полю связанная таблица справочник. Так по этим полям будет легче и быстрее делаться выборка в случае поиска по фильтру.
3) Varchar используется только там где пользователь вводит что-либо "от руки", в остальных случаях это практически всегда связь со справочной таблицей, в которой перечислены возможные значения.

Что касается еластиксерча, это механизм поиска в текстовых полях, мощный и удобный, но в данном случае избыточный, просто надо нормально спроектировать. Это все равно что сделать кривой медленный код и потом вешать кэширование чтобы хоть как то работало на приемлемой скорости. Типа, "лыжи по асфальту не едут, давайте лыжнику в ж... вставим ракету помощнее!".

Answer 2

[Rou1997]

Ничего не понятно, "Adresa" у одной квартиры несколько адресов, или все-таки "Adres"?
Если только один адрес, и не требуется отдельно хранить каждую улицу, дом и т.д., то здесь изменить нечего, действительно varchar или text, а если допустим много - то либо нужно создавать еще одну таблицу адресов и связывать, либо хранить как массив JSON, второе проще.
А вот разделы стоит именно вынести в отдельную таблицу разделов и связать через FOREIGN KEY, в отличие от связей "многие-ко-многим" внешний ключ реализуется намного проще, и в самой БД и в MVC-фреймворках.
Еще, почему везде varchar(200), если хотите изначально иметь максимальную гибкость, и оптимизировать по мере надобности, то лучше уж TEXTтогда.
И мелочь: названия столбцов, если проект только ваш или вы главный разработчик, то это на ваше усмотрение, но обычно вместо транслита применяют полноценный перевод.

Comments

[Сергей Семенко]

А как FOREIGN KEY может заменить связь? Внешние ключи просто помогают сохранить целостность данных.

[Rou1997]

Сергей Семенко: "Внешние ключи просто помогают сохранить целостность данных." - сами-то можете объяснить, что это значит?

[Сергей Семенко]

Rou1997: база данных будет сама проверять наличие записи в другой таблице при "связывании" + есть парочка триггеров (on update, on delete).

[Растишка]

Rou1997: Что тут объяснять то? Если прописаны FOREIGN KEY то не получится сделать связь с несуществующей строкой или удалить строку, не изменив ссылающийся на него ID. => данные останутся целостными.

[Rou1997]

Сергей Семенко: Я имел в виду саму архитектуру, при которой создается таблица с адресами, и id из нее вставляется в основную таблицу, а FOREIGN KEY не обязателен, но действительно обеспечивает проверку и действия при обновлении и удалении, а еще облегчает генерацию моделей в MVC-фреймворках, например с помощью gii в yii2.

Answer 3

[Евгений]

elasticsearch