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

Тогда postgres здесь как бы не упёрся, берём монгу или другое документо-ориентированное хранилище и привет. Суть именно EAV в сохранении ограничений целостности БД, хоть в какой-то мере.


ПомидорСкажем администратор системы решил быть таким и таким полям, а модератор хочет обойти это решение, хочет добавить дополнительное поле, это очень легко решается как и в случае с eav моделем.

Это бардак.

ПомидорВ случае с постгерс ни не заставляет все поля кроме первичного ключа загонять в жейсон поле. Жейсон поле просто приятная возможность чтобы не плодить лишние сущности в базе, причем очень эффективная.

Эффективная, но это не альтернатива EAV, в полной мере так сказать. Это другое. Например, со стороны приложения запихать каких-то полей, чудоковатых, при чём у каждой записи вообще свой набор полей. Или сохранить объектную структуру документа, да много чего. Но это не EAV.

Кот МатроскинhVostt Но это не EAV.
Какая задача, легко решаемая EAV, не может быть решена при помощи подхода с JSON/XML?

Ну давайте посмотрим. Независимость от конкретных РСУБД. Ограничения целостности (не может быть значений отсутствующих атрибутов). Расширенный EAV мог бы вести типовые значения в отдельных таблицах или колонках, т.е. спектр типов, поддерживаемый БД шире JSON, даже в понятиях ANSI. Ну XML слишком жирный, хотя поддерживаемых примитивных типов больше.

И "решена", имеется в виду средствами БД. Так как если сводить на уровень приложения, вообще всё можно решить, даже без БД ))

SERG1257hVosttСуть именно EAV в сохранении ограничений целостности БД, хоть в какой-то мереЭто какие такие ограничения накладывает EAV?

Нельзя создать значение для отсутствующего атрибута. Можно запретить удаление атрибута при наличии значений. Если создавать типовые колонки или таблицы значений, можно задать соответственно типовые ограничения, в том числе ссылки.

Кот МатроскинВполне достигается :) Вряд ли найдется СУБД, которая не сможет хранить XML/JSON. Возможно, не получится эффективно искать в них - ну так опаньки, "независимость от конкретных СУБД" вообще плохо сочетается с максимальной эффективностью, тут снявши голову по волосам не плачут.

Вот не надо. Классический EAV, будет примерно одинаковый на широком спектре СУБД и примерно одинаково будет работать по скорости.

Инструменты для работы с XML/JSON в разных СУБД, если они есть, то работа с ними отличается полностью. А хранить типа в string, ну это извините, уже за рамками дискуссии. Можно всю БД таким образом хранить в одном поле одной записи в XML.


Кот МатроскинУ XML и JSON внезапно есть схемы :)

Динамические схемы? Которые проверяются со стороны БД? Нет? Тогда не очень тут говорить :)

Кот МатроскинВозможности которых гораздо шире, чем "не может быть значений отсутствующих атрибутов". Так что тут минус у EAV.

Это поддерживается СУБД? В динамике? Нет? Ну а чего тогда.

Кот МатроскинЧто имеется в виду под "динамическими схемами"?

Значит новые атрибуты добавляются/изменяются как данные.

Кот МатроскинhVosttпропущено...


Значит новые атрибуты добавляются/изменяются как данные.
Они добавляются и изменяются, но не "как данные" (и это, опять же, плюс, а не минус). Путать в один винегрет данные и метаданные - это родимое пятно EAV, странно это считать достоинством.

В этом весь смысл EAV, а не достоинство. Иначе нафига мне эти JSON с XML-ем упёрлись, если я просто могу создавать таблицы и налаживать между ними связи? Как обычно.

tip78,

На самом деле JSONB действительно лучше, чем EAV, если не принимать во внимание такие недостатки как:

крайне сильная зависимость от конкретной СУБД и даже от конкретной её версии, это значит, что для другой СУБД придётся переписать всё, в то время как EAV останется рабочим на стандартном диалекте SQL

очень слабый контроль целостности со стороны БД

Хранение структур данных в таблицах с возможностью поиска, индексации, и построения запросов это маст хев однозначно. Полноценное документное хранилище в реляционке, конец войнам и спорам.

Но это не EAV, не является её альтернативой, и не решает задач так, как их решает EAV.