hVosttПомидорВот и выяснили что полюбому вам придеться проверять данные на уровне приложения. А теперь чтобы по типу данных была целостность, вам надо еще немного потрудиться чем простое EAV. А в простом EAV данные же храняться в текстовом формате. Для каждого типа создать свою таблица хранения, тогда давайте посмотрим как вы их потом соберете в одну!
А какие проблемы? Между прочим на EAV можно создать типы с JSON-ом И на жейсон атрибут тоже можно запихнуть жейсон, будет иерархия жейсонов, которая кстати нативная
hVosttПомидорПроверка на наличие атрибута большая проблема на жейсоне? Я вам наверху уже нарисовал примерную схему ограничения для произвольных атрибутов. Надеюсь вы не собираетесь руками что то подправлять в БД? Внешний ключ единственная проверка СУБД, а все остальное вам опять таки придеться делать на стороне приложения, тогда какая разница на одну проверку меньше или больше?
Разница в том, что статическая или динамическая схемы -- это всё равно схемы. А контролировать данные, которые должны соответствовать схеме должна БД, а не приложение. По крайне мере EAV это решает, JSON не решает.Как БД контролирует данные которые должны соответствовать схеме? Например хотим в динамическом атрибуте хранить период даты, как она это проконтролирует?
hVosttПомидорЯ их сравниваю только потому что ту задачу которую мы решаем на основе модели eav можно эффективно решить применив немного другой подход с жейсоном.
Ну json не решает задачь EAV. JSON + приложение, да. И то, с натягом. С большим.
Почему с натягом? Полностью контролирует. По вашей логике то и бизнес правила тоже с натягом валидируются на уровне приложения? Если так, то где еще проверять данные?
hVosttПомидорС точки зрения хранения данных конечно это совсем разные подходы, но под словом "аналог" я подразумеваю решения задачи.
Ну так какая задача? Хранить любой мусор? Конечно, JSON здесь намного лучше. Хранить строгий динамический набор атрибутов? Не, эту задачу JSON не решает. Там всё равно будет мусор, даже если ПО считает, что нет. С точки зрения БД, это какая-то куча данных. И всё.Задача простая. Есть набор объектов, которые одного типа, имеют как похожие так и непохожие наборы атрибутов. И в дальнейшем могут добавляться атрибуты. Не могу понять почему вы все время указываете на мусор данных в случае жейсон.
hVosttПомидорА вот для пользователей которым доступ к бд ограничен пользовательским интерфейсом, так они даже не почувствуют eav это или жейсон, они не смогут создать значение для отсутствующего атрибута. Им подавай ограничения на уровне приложения и скорость.
Это понятно. Но это за рамками дискуссии, ну очень далеко. Все это взаимосвязанно. Ведь вы же не проектируете схему базы данных не учитывая дальнейшую ее эксплуатацию.
hVosttПомидорНу так данный спор происходит на конкретной модели данных. В статье указан объем.
Так "объём", это не только количество записей. Если говорить про динамику, то это постоянно набирающая обороты сложность. Т.е. сложность растёт без вмешательства программиста. Проблемы, которые JSON не решает, не показаны в статье. Только скорость на одноклеточном примере, но с большим количеством записей.
hVosttПомидор
1.
2.
3.
4.
5.
SELECT name
, properties ->> 'color'
, properties ->> 'country'
FROM entity_jsonb
WHERE id = 120;
Напишите аналог этого запроса на модели EAV. Тем более я могу через приложение гибко контролировать select часть, а в EAV? У вас там запрос полностью измениться.
Историю я веду не на колонки, а на строки. Занимает много места, но сейчас это уже не проблема. Зато позволяет сразу вытаскивать нужную информацию не применяя жойны.
1.
2.
3.
4.
5.
select e.name,
(select ev.value from e_values ev where ev.eid = e.id and ev.aid = 4) as color,
(select ev.value from e_values ev where ev.eid = e.id and ev.aid = 5) as country
from e_entities e
where e.id = 120
буков больше?
Такие запросы также могут генериться приложением, никто руками их не пишет.
История на колоноки здесь бесплатно.
Возможность конвертить тип, не теряя данных бесплатно.
Делать быструю "колоночную" аналитику бесплатно.
Хранить к дополнительные данные к каждому значению бесплатно (на JSON вместо значения придётся делать структуру вместо примитива, а это увеличит сложность запросов просто драматически).
Быстрое обновление, проставить значения атрибута хоть для +100500 сущностей без проблем.
Контроль со стороны БД.
Настоящие ФК в значениях атрибутов.
Расширение вширь и в глубь, без изменения существующего кода.
Ну и конечно, сильная независимость от вендора, для кого-то это фигня, кто сидит пожизненно плотнячком на конкретной субд. Для нас, например, это важно, и это окупилось уже многократно.
Хорошо, для вас много букв не проблема. А как насчет скорости этого запроса? Ведь автор как раз это и проверил, и пришел к выводу что жейсон метод в 15 тыч. быстрее. :) История на колонки как бесплатны? Можете подробнее в этом месте объяснить. Меняем для какого то объета значения динамического атрибута 'color' с RED на BLACK. Конвертить тип данных не бесплатно, а нагрузга для системы. Для жейсонб это уже нативно. :) Делать быструю "колоночную" аналитику делают немного другим методом, например можно в редис скинуть. :) Она уж точно будет быстрее вашей аналитики. Какие дополнительные данные к каждому значению можете хранить? Я не представляю. Жейсон изначально поддерживает вложенность, или дополнительные атрибуты к жейсон объекту. И сложность не растет драматически.
авторFor updating the data, this resulted in these execution times (in ms). Note that the scale is logarithmic:
Here, we see that the JSONB is much (>50000x) faster than EAV when not using any indexes, for the reason mentioned above. When we index the foreing key columns the difference is almost eliminated, but JSONB is still 1.3x faster than EAV. Notice that the index on the JSONB column does not have any effect here, as we don’t use the properties column in the criteria.
Как видите то что в вашем методе без проблем, в случае с жейсоном минимум 1.3 быстрее. :) Расширение вширь и в глубь жейсон метод не ограничивает ни как. Сильная зависимость от вендора для меня действительно не проблема на данный момент. Выбираю инструменты сам. Но вашу точку зрению я изначально понимал. Просто думаю скоро все вендоры реализуют такие фичи в любом случае.
Если не секрет то с какой субд на какую субд вы прыгнули?
