ещё один недостаток

типы, не надо рассказывать про десериализацию дат, десятичных числовых полей и прочее

Кот Матроскинtip78Искать по глубокому дереву всё ещё будет медленнее,
В третий раз - чтобы эмулировать EAV, никакие "глубокие деревья" в JSON не нужны.

Нельзя эмулировать EAV, JSON-ом.

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

Если считать "смыслом EAV" создание винегрета из данных и метаданных - то вполне возможно в этом ей нет конкуренции :) Но я как-то считал ее предназначением динамическую настройку атрибутов сущности. И эту задачу JSON/XML вполне решают, с лучшим нежели EAV контролем целостности.

Нет не решают. JSON хранит какие угодно данные, максимум что может обеспечить СУБД, это валидность JSON-а, но не содержание. В EAV мы ведём и схему и данные, и это контролируется БД. Если вести некий гибрид, типа EA-JSON (где V это JSON), то БД не будет гарантировать, что в JSON там не хранится какой-то полный бред, ну никак. А также не может запретить удалить атрибут при наличии значений. А также невозможно полноценное ведение значений -- ссылок.

Это не + или -, это просто факты. Поэтому JSON это не EAV, это совершенно разные решения, которые не решают одно и ту же задачу, они решают разные задачи.

Вы почему-то настойчиво пытаетесь проявить своё негативное отношение к модели данных, и поэтому делаете не верные выводы.

Кот МатроскинНе знаю как JSON, но содержимое XML-ей, их соответствие схеме и т.п. СУБД вполне умеет контролировать. Это просто факты :)

Представим UI админки интернет-магазина. Заходит админ, открывает раздел "атрибуты товара", добавляет новый атрибут, допустим, «Цвет», указывает тип, сохраняет. В БД улетает обычный INSERT, который добавляет в схему новое поле. И он с этого момента начинает контролироваться БД. Можно и список всех атрибутов получить как обычный запрос, и каких-то левых Value засунуть не получится, только в рамках заданных атрибутов.

Расскажите, как у вас это будет организовано на XML.

tip78и как это вам удалось собрать 2 этих утверждения в одном сообщении? )

Согласен, глупо получилось. Я хотел сказать, если вам надо хранить произвольные структуры данных, то JSON(B) лучше EAV.

Т.е. это лучше вот этого





tip78Я вот когда пробовал заменить свои задачи на JSONB в итоге плюнул.

Ну вот и вы туда же Заменить задачи?

В общем, мне к сказанному больше нечего добавить, всё довольно очевидно и понятно.

L_argoВ БД улетает обычный INSERT, который добавляет в схему новое поле .Опечатка ? Новую запись ?

Новый атрибут, поле с точки зрения динамической модели данных.

Кот Матроскинgoogle "SQL Server xml schema collection".

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

ПомидорЗачем монго когда эту задачу эффективно решает postgres? Я привел jsonb только для моделей которые требуют динамические аттрибуты (аналог eav), все остальное решается как обычно в рсубд.

Нет, не аналог EAV. Динамические атрибуты без схемы, это вообще любое хранилище, без схемы, хоть текстовые файлы. Таким макаром и обычный блокнот можно назвать аналогом чего угодно.

ПомидорЧто значит бардак? Разве не администратор интернет магазина решает что для конкретной категории товаров нужны определенные аттрибуты с указанием типа аттрибута, ограничением определенных значений которые она может принимать и так далее? Тоже самое можно сделать и для жейсона, но как я уже написал валидация данных в вашем случае будет ну уровне базы данных, а в моем случае на уровне приложения.

Речь идёт именно о СУБД. На уровне приложения я могу данные вообще хранить в key-value store и всё-всё-всё проверять на уровне приложения, или даже в текстовых файлах хранить. Аналог? Что за детский сад?

ПомидорЗдесь почти разницы нету

Ну так и все ограничения целостности, транзакции, и всё остальное делайте на уровне приложения. Зачем говорить вообще тогда о БД. Храните хоть всё в памяти, и сбрасывайте дамп на диск. Разницы ведь почти нет.

ПомидорА вот когда надо будет запросы с фильтрацией, то жейсон уже вырывается вперед, а eav остается далеко позади, что и сказано в указанной мной статье.

В указанной вами статье, SELECT по EAV с индексом быстрее, чем все вариации с JSONb. Обновление с индексом чуть-чуть медленнее. По собственному опыту, у нас есть внедрённая система на EAV, довольно крупная по мерками enterprise, и всё работает шустро.

Что касается лучшей реализации, то делать проекции на классических таблицах, добавляя колонки динамически в таблицы, не оставляет вообще никаких шансов по скорости ни EAV, ни JSONb, если уж вас так интересует производительность.

И, повторюсь, JSONB не явяется аналогом EAV.

ПомидорПро какую независимость РСУБД вы имеете ввиду? Если хорошая фича реализована в одной системе, то скоро она станет стандартам.

ANSI SQL. Это будет работать сейчас в абсолютном большинстве СУБД. «Скоро» по-вашему, это когда? Когда для работы с JSON в пятёрке самых крупных БД будет одинаковый синтаксис запросов и набор операций? Лет через 10?

ПомидорЧем же это не EAV? Что вы понимаете под EAV? Хорошо, давайте сперва определимся какую задачу решает EAV модель, как она контролирует целостность данных, проводит валидацию, как добавляются новый записи (новый аттрибут товара). И я приведу на жейсоне решение которая будет тоже самое делать.

Я уже давно жду вот такой пример:

1. Администратор интернет-магазина через UI приложения добавляет атрибут для товаров.
2. Администратор добавляет значения этого атрибута для некоторых товаров.
3. Администратор удаляет атрибут, значения атрибута удаляются.

Для JSON(B)