Задать вопрос

Делать 1 большую таблицу или разбивать на части?

Привет!

Есть объект недвижимости, у каждого огромное количество параметров (более 20).
Например, параметров участка 5 штук, параметров предложения продажи ~10, параметров предложения аренды тоже около 10 и так далее.

Как лучше: делать 1 большую таблицу со всеми полями или делить на таблички по сущностям и связывать 1 к 1 по ключу и есть ли какая-то разница?
  • Вопрос задан
  • 1100 просмотров
Подписаться 4 Простой 1 комментарий
Решения вопроса 1
Maksclub
@Maksclub
maksfedorov.ru
Чтобы не громоздить тонны колонок и делать по канонам 3 нормальной формы — разделяют сущности, атрибуты и их значения отдельно.

Свойства обычно хранят отдельно( у них могут быть свои поля)
5a68a3b0baf0c785050166.png
а значения к ним тоже отдельно (EAV)
product_id, feature_id, value (где featured_id — id свойства из таблички выше)

пример с моего интернет-магазина — 1 товар, много характеристик
5a68a6c2b19f2067082314.png

Пример запроса:
SELECT   p.id, p.url, p.name
FROM e_products p		
WHERE 1 
AND p.id in (SELECT product_id FROM e_options WHERE feature_id=8 AND value in('Бежевый','Белый') )
AND p.id in (SELECT product_id FROM e_options WHERE feature_id=1 AND value in('Лето 2011') )
время выполнения запроса — 0.019 s для 10 тыс товаров, 100тыс значений свойств и десятка свойств

В запросе два параметра фильтра (1 значение коллекции и 2 значений цвета, выше можете увидеть в табличке)
как понимаете — строку с нужным свойством подставляете в зависимости от GET запроса...

* Можно упростить — вместо feature_id хранить сразу название параметра, но лучше сразу разделите... чтобы можно было параметру поставить напрмиер поле включать или нет его в фильтр и задать порядок, или нужно будет выводить поля в саму форму фильтра (гонять большую таблицу — так себе решение)
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
solotony
@solotony
покоряю пик Балмера
"лучше" или "хуже" - применительно к чему ?

если к теоретическим "нормальным фомам" - это одно
если к скорости выборки - это другое
если к объемам хранимых данных - это третье

например на скорость будут влиять - какой диск, какая б/д, какие таблицы, какие доступны лимиты по памяти, по процессору.

20 - это не огромное значение. вот когда их 200 или 2000 ... нужно смотреть на определенность этих параметров, на их дублирование. если они все определены - тогда эффективнее (с любой точки зрения) их хранить в одной таблице, если из 20 заданы 5 - тогда разбивать на сущность/атрибуты/значения (я бы так поступил).

опять же - если параметры неизменяемы и по ним нет выборки - может их эффективнее хранить в одном поле в JSON ?

в общем все очень индивидуально относительно конкретной задачи и универсального рецепта нет.

а конкретно в случае бд недвиги я бы пошел таким путем

1) таблица объектов (тип объекта, тип сделки аренда/продажа)
2) таблицы параметров по каждому типу объектов
3) таблицы параметров по каждому типу сделок
Ответ написан
Комментировать
@SemenDemon
Смотря какой объем вы хотите хранить. одну большую таблицу со всеми полями точно хранить не стоит. Если среднее значение объектов до 1млн. то отлично подойдет EAV. Если больше (все условно) возможно правильнее будет JSON.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы