tip78вы даже не умеет создавать колонки с типом date?
Ваш поверхностный пример оставляет очень много вопросов, и у меня есть сомнения что у вас получиться это сделать именно с моделью EAV.

hVosttПомидорКак БД контролирует данные которые должны соответствовать схеме? Например хотим в динамическом атрибуте хранить период даты, как она это проконтролирует?

Вариантов несколько, от разных таблиц для каждого типа, до одной таблицы с разными полями. Так или иначе, в поле типа timestamp вы не засунете, например, GUID, строку или дробное число. В JSON можно засунуть что угодно. В БД больше типов, которые она контролирует.
Все EAV считают костылем в рсубд, но вы тут делаете "открытия". Вы конечно можете засунуть в разные поля. Поэтому я прошу вас показать пример как вы потом будете делать отчеты, собирать данные обратно в один объект. :)

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

Нет, не контролирует. Foreign Key, например. Типы. Бизнес-правила это совершенно другая опера. Есть конечно решения, которые пытаются вести бизнес-правила на уровен БД (триггеры, ХП...), но я абсолютный противник этого, так как это прошлый век и вообще убого.

hVosttПомидорЗадача простая. Есть набор объектов, которые одного типа, имеют как похожие так и непохожие наборы атрибутов. И в дальнейшем могут добавляться атрибуты. Не могу понять почему вы все время указываете на мусор данных в случае жейсон.

Потому что с точки зрения БД, это структурированная куча.

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

Всё верно, поэтому ограничения целостности БД, это очень важная составляющая при проектировании. При использовании JSON, этим приходится пожертвовать, понадеясь на то, что ПО всё разрулит. Но это плохая практика.

hVosttПомидорХорошо, для вас много букв не проблема. А как насчет скорости этого запроса? Ведь автор как раз это и проверил, и пришел к выводу что жейсон метод в 15 тыч. быстрее.

В 15 тыс.? Нет конечно, не быстрее. Скорость уступает статической схеме. Но и JSON уступает статической схеме, так что.

Если вас интересует в первую очередь скорость, вы должны отказаться от EAV, JSONB и прочих костылей. И динамически изменять саму схему БД, чтобы иметь максимальную производительность, а также хорошую сопровождаемость запросов.

hVosttПомидорИстория на колонки как бесплатны? Можете подробнее в этом месте объяснить.

Достаточно вести в любой таблице (Timestapm, EntityId, AttributeId, Value), так как у вас идентификаторы атрибутов. В JSON их нет, только названия колонок, в EAV у атрибута может быть сколько угодно параметров.

hVosttПомидорКонвертить тип данных не бесплатно, а нагрузга для системы. Для жейсонб это уже нативно. :)

Абсолютный ноль нагрузки в случае EAV. Меняем тип атрибута, и может сконвертить все значения атрибута в новый тип, что сконвертится — запишется, при этом все старые значения старого типа останутся в неизменном состоянии, т.е. можно вернуться обратно и получить все свои старые значения обратно. Бесплатно.

Для JSON придётся выполнить изменение всей структуры, так как в JSON нет UPDATE для одного атрибута (синтаксически он есть, но по факту, это изменения всего набора). Конвертирование убивает старое значение, если вы конечно не хотите оставить всё в неопределённом состоянии, когда поле JSON сразу хранит данные разного типа, что очень очень плохо.

hVosttПомидорДелать быструю "колоночную" аналитику делают немного другим методом, например можно в редис скинуть. :)

Да, можно. Но это не бесплатно.

hVosttПомидорОна уж точно будет быстрее вашей аналитики.

За счёт чего, интересно? Тут унылая БД, а там термоядерное волшебство на стероидах?

hVosttПомидорКакие дополнительные данные к каждому значению можете хранить? Я не представляю. Жейсон изначально поддерживает вложенность, или дополнительные атрибуты к жейсон объекту. И сложность не растет драматически.

Да легко, например, кто автор изменений данного значения, когда изменилось значение этого поля (а не всей строки). Т.е. ещё и бесплатный аудит на борту :)

Да, джейсон поддерживает вложенность. Но это опять таки, не контролируется БД. Что вы там вложили, с точки зрения БД это та же куча. И запросы станут сложнее. А для EAV они вообще не изменятся.

hVosttПомидорКак видите то что в вашем методе без проблем, в случае с жейсоном минимум 1.3 быстрее. :)

Как я уже сказал. Если хотите скорости, то EAV вместе с JSONB отстают от статики. Ведите проекции в статических таблицах. Для EAV можно делать материализованные представления, где требуется мега-скорость, но это те же костыли, которые можно делать и для JSON. Поэтому для скорости и производительности, нужно выбирать другие подходы, а не менять одни костыли на другие.

hVosttПомидорЕсли не секрет то с какой субд на какую субд вы прыгнули?

Мы поддерживаем минимум три СУБД в наших проектах: MS SQL, Oracle, Postgres. За счёт архитектуры, позволяющей просто писать провайдеры для СУБД, мы смогли для отдельного случая поятнуть ещё одну СУБД без существенных затрат.

Это не значит, что мы вообще, например, отказываемся от JSONB, просто надо понимать, что это структура по сути куча. Надо всегда это понимать, и работать с ней соответствующим образом.

Прошлое сообщение было по ошибке отправлено. Не могу отредактировать. Поэтому это новое.
hVosttпропущено...


Вариантов несколько, от разных таблиц для каждого типа, до одной таблицы с разными полями. Так или иначе, в поле типа timestamp вы не засунете, например, GUID, строку или дробное число. В JSON можно засунуть что угодно. В БД больше типов, которые она контролирует.
Все EAV считают костылем в рсубд, но вы тут делаете "открытия". Вы конечно можете засунуть в разные поля. Поэтому я прошу вас показать пример как вы потом будете делать отчеты, собирать данные обратно в один объект. :)
hVosttпропущено...
Нет, не контролирует. Foreign Key, например. Типы. Бизнес-правила это совершенно другая опера. Есть конечно решения, которые пытаются вести бизнес-правила на уровен БД (триггеры, ХП...), но я абсолютный противник этого, так как это прошлый век и вообще убого.
Контролируется запросто. И типы контролируются. Бизнес правила определяют тип данных. Поэтому отделять их от базовых проверок данных не могу представить.
hVosttпропущено...
Потому что с точки зрения БД, это структурированная куча.
Я БД рассмотриваю просто как хранилище. Что я туда положу и в каком виде, в таком виде я и получаю.
hVosttпропущено...
Всё верно, поэтому ограничения целостности БД, это очень важная составляющая при проектировании. При использовании JSON, этим приходится пожертвовать, понадеясь на то, что ПО всё разрулит. Но это плохая практика.А почему ПО не может разрулить? Поэтому я спрашивал немного раньше, вы что голыми руками лезете в БД что то подправить? Это хорошая практика?
hVosttпропущено...
В 15 тыс.? Нет конечно, не быстрее. Скорость уступает статической схеме. Но и JSON уступает статической схеме, так что.

Если вас интересует в первую очередь скорость, вы должны отказаться от EAV, JSONB и прочих костылей. И динамически изменять саму схему БД, чтобы иметь максимальную производительность, а также хорошую сопровождаемость запросов.
Все зависит от структуры данных и операций над этими данными. И да, для этой задачи жсонб отлично подходит, и превосходит EAV модель в рсубд. А то что вы теоритизируете это конечно отлично, и всем известно, но для нашего обсуждения малопригодно.
hVosttпропущено...
Достаточно вести в любой таблице (Timestapm, EntityId, AttributeId, Value), так как у вас идентификаторы атрибутов. В JSON их нет, только названия колонок, в EAV у атрибута может быть сколько угодно параметров.
В каким виде у EAV атрибута может быть сколько угодно параметров? И я вам напишу жейсон решение :).
hVosttпропущено...
Абсолютный ноль нагрузки в случае EAV. Меняем тип атрибута, и может сконвертить все значения атрибута в новый тип, что сконвертится — запишется, при этом все старые значения старого типа останутся в неизменном состоянии, т.е. можно вернуться обратно и получить все свои старые значения обратно. Бесплатно.

Для JSON придётся выполнить изменение всей структуры, так как в JSON нет UPDATE для одного атрибута (синтаксически он есть, но по факту, это изменения всего набора). Конвертирование убивает старое значение, если вы конечно не хотите оставить всё в неопределённом состоянии, когда поле JSON сразу хранит данные разного типа, что очень очень плохо.
Ничего в жейсоне не будем менять, данные там не будут конвертироваться, они уже лежат в нужном типе. :).
Кстати вопрос, зачем вам конвертировать старые значения на новые? Это уже плохая практика. :) Вы же писали что контролируете тип данных, и тут на тебе, приходиться конвертировать почему то значения атрибутов на новые значения. :) В жейсоне если придется как преобразовывать значения, то и старое можно оставить до того момента когда уже точно знаем что можем удалить, подчистить, и новое уже применять. А вам придется туго чтобы такое проделать. :)
hVosttпропущено...
Да, можно. Но это не бесплатно.
Бесплатно если учесть что она не только эту задачу выполняет, а кучу еще в добавок. Я не представляю высоконагруженную систему которая не использует редис или его подобною систему в придачу к рсубд.
hVosttпропущено...
За счёт чего, интересно? Тут унылая БД, а там термоядерное волшебство на стероидах?
Не термоядерное волшебсто, а чистая математика.
hVosttпропущено...
Да легко, например, кто автор изменений данного значения, когда изменилось значение этого поля (а не всей строки). Т.е. ещё и бесплатный аудит на борту :)

Да, джейсон поддерживает вложенность. Но это опять таки, не контролируется БД. Что вы там вложили, с точки зрения БД это та же куча. И запросы станут сложнее. А для EAV они вообще не изменятся.
Прошу показать структуру данных, тогда и можно увидеть как вы отслеживаете историю данных. Почему то мне кажется что у вас только поля created_at, created_by, updated_at, updated_by. :) Это конечно отлично, дает быструю информацию, но это может оказаться не полная история кто что где какие данные менял на что.
hVosttпропущено...
Как я уже сказал. Если хотите скорости, то EAV вместе с JSONB отстают от статики. Ведите проекции в статических таблицах. Для EAV можно делать материализованные представления, где требуется мега-скорость, но это те же костыли, которые можно делать и для JSON. Поэтому для скорости и производительности, нужно выбирать другие подходы, а не менять одни костыли на другие.
Может и отстают. Но я за жейсон метод пишу не только из-за этого. Она пока дает преимущество в удобстве, скорости использования в отличие от EAV. Вести проекции в статических таблицах можно, но это уже костыль очень большой. Никому это и даром не нужно. Поэтому и придумали EAV и подобные ему методы. :)
hVosttпропущено...
Мы поддерживаем минимум три СУБД в наших проектах: MS SQL, Oracle, Postgres. За счёт архитектуры, позволяющей просто писать провайдеры для СУБД, мы смогли для отдельного случая поятнуть ещё одну СУБД без существенных затрат.

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