ГхостикVetalесли нужно было обеспечить клиентов продуктом, где схема данных заранее неизвестна и должна конфигурироваться в рантайме администратором системы, то EAV был единственным вариантом.Чем EAV в этом отношении лучше чем упрощенное, грубо говоря, средство разработки БД?
Допустим, сделал я конфигуратор, который хранит метаданные, умеет добавлять/удалять поля и таблицы и составлять sql-запросы. Чем это хуже EAV?Тем, что "добавляет/удаляет поля и таблицы". И рано или поздно, но по "живым" данным...
Ошибка в метаданных... Случайно(!) подсунули "не ту конфигурацию"...

Кот МатроскинEAV плохо поддерживает ссылочные данные,Не намного хуже, чем любая "стандартная" схема - просто добавьте "V со ссылкой"...

Кот Матроскинsphinx_mvпропущено...
Не намного хуже, чем любая "стандартная" схема - просто добавьте "V со ссылкой"...
А ссылочная целостность?А кто сказал, что для "E" нельзя сделать "А", "V" которого ссылается на другое "E"?
С декларативной ссылочной целостностью... И вообще можно хранить строго типизированные данные...
Схема усложнится, но можно.

Гхостикsphinx_mvпропущено...
Тем, что "добавляет/удаляет поля и таблицы". И рано или поздно, но по "живым" данным...
Ошибка в метаданных... Случайно(!) подсунули "не ту конфигурацию"...
1. Бэкапы никто не отменялНадеюсь, Вы в курсе, сколько времени может занимать восстановление базы данных из бэкапа?
И Вы в курсе, что все это время база физически не доступна ?
Гхостик2. Удаление можно и "логическое" сделатьНу, и чем это отличается от EAV при изменении метаданных его модели?
Гхостик3. В EAV удалить поле с данными ничуть не сложнее, и испортить их накатом скрипта для неверной версии тожеНет необходимости физического удаления стрруктур и данных в EAV. Изменить и восстановить модель проще, чем поднимать бэкап. И работать с несколькими разными версиями моделей в EAV можно одновременно - на одном наборе дланных.

Кот Матроскинsphinx_mvпропущено...
А кто сказал, что для "E" нельзя сделать "А", "V" которого ссылается на другое "E"?
С декларативной ссылочной целостностью....
Кто ее поддерживать будет - некое промежуточное API?Ну, и какое "промежуточное АПИ" поддерживает на любом современном SQL-сервере FOREIGHN KEY ?!
EAV всего лишь очень сильно нормализованные данные, а на то, до какой степени данные нормализованы (или вообще никак не нормализованы) любому SQL-серверу должно быть сугубо "с высокой колокольни". В середине 2010-х SQL-сервер должен уметь поддерживать внешние ключи - и уметь это делать хорошо .
Кот МатроскинА оптимизатор эту "декларативную ссылочную целостность" использовать будет?Назначение ограничений ссылочной целостности не в том, чтобы ее "использовал оптимизатор", а в том, чтобы не допускать вставку в соответствующее поле неверных значений ключа.
Кот МатроскинЭто и называется "поддерживается плохо". Смотрите мое первое сообщения - я там как раз говорю, что в EAV можно хранить ссылочные данные, но криво и через задницу.Интересная "задница"... :)
Как повесить FOREIGHN KEY между двумя "обычными" таблицами в "обычной" сжеме - то "ничего страшного"... Но как сделать то же самое в EAV - так сразу "фобос и деймос" (с)

Гхостик> Надеюсь, Вы в курсе, сколько времени может занимать восстановление базы данных из бэкапа?
> И Вы в курсе, что все это время база физически не доступна ?
Это не аргумент за EAV.Это - аргумент против Вашего предложения по изменениям модели ребилдить схему данных.
ГхостикПотому что и в ней рестор меньше времени не займет.Займет! :)
В EAV "необходимо и достаточно" восстановить/наложить на существующие данные только старую/новую схему данных.
Гхостик> Ну, и чем это отличается от EAV при изменении метаданных его модели?
Ничем. Значит, это не аргумент в пользу EAV.Вы слегка запутались: это был Ваш аргумент в пользу жесткого ребилда схемы. И этот Ваш аргумент оказался немножко бесполезным...
Гхостик>Нет необходимости физического удаления стрруктур и данных в EAV.
Нет необходимости удаления таблиц и полей и в реляционной схеме тоже. Ненужные поля делаются nullable, и в таблице метаданных проставляется признак неактуальности начиная с текущей версии.Во-первых, "на-лицо" - завязка на вендора...
Во-вторых, с "движением вперед" - все более/менее понятно. Но как быть с "движением назад"?
Гхостик> И работать с несколькими разными версиями моделей в EAV можно одновременно - на одном наборе дланных.
Вот поддержка на уровне СУБД . Поддержка ручками - что в реляционной, что в EAV схеме будет представлять примерно одинаковую сложность.Когда-то давно под очень сильным впечатлением от статей Анатолия Тенцера примерно за два с половиной месяца я "нарисовал" на MSSQL EAV-хранилище. С пользовательским интерфейсом... С возможностью версионирования схемы... С разграничением прав пользователей как на типы сущностей, так и на отдельные атрибуты типов... С наложением и суперпозицией типов сущностей - сущность одного типа можно было отмапить в другой тип просто указав идентификатор целевого типа...
Реализация была готова к включению в релиз, но "контора накрылась"...
ГхостикА аргументы против EAV есть - это худшая производительность и сложность написания запросов по сравнению со стандартной реляционной схемой."Худшая производительность" и "сложность написания запросов" при нынешнем тотальном увлечении ORMами - это ну, очень весомо...
Во-вторых, только полный (цензура) будет использовать EAV для чего-нибудь еще, кроме хранения редко меняющихся данных.
Ну, а переписывать весь DAL после изменения "стандартной реляционной схемы" - это несказаемо "сексуально"!

Кот Матроскинчтобы сделать обсуждение более предметным - можно пример EAV-схемы с возможностью использования стандартных foreign key
в атрибутах?"Рисовать" не буду, но "расскажу" в двух словах: в "стандартном EAV" добавить в метаданные для атрибутов признак "ссылочный", а в данных еще одну "value"-таблицу, имеющую ссылку (внешний ключ) "значимого" поля на ключ в "entity" - вроде бы очевидное решение...
Про "одинаковость" типа данных полей для создания внешнего ключа, думаю, упоминать нет необходимости?

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

А ссылочная целостность?Никогда не понимал, зачем нужна СЦ . Эта фича бесполезна и больше мешает, чем помогает.
Вставку/удаление (в т .ч. логическое) нужно делать процедурой , кот. сначала проведет сто проверок и только потом удалит или спрячет. Или выдаст внятное сообщение о причине невыполнения.Главное, что Вы принципиально не возражаете, против необходимости поддерживать ссылочную целостность. Но процедуру , которая это будет делать, сначала нужно написать - в отличие от декларативной поддержки ссылочной целостности.
К тому же, в следствие особенностей по-командного выполнения запросов в процедуре результат такого контроля может давать неадекватные результаты: между разными даже последовательными командами походит некоторое время, в течение которого в параллельной сессии данные могут оказаться уже измененными и не соотвествовать результатам проверки, выполненные в текущей сессии.
LSV СЦ тормозит . Дико мешает перезаливать данные (иногда это нужно).Потому и нужно внимательно думать, где это действительно необходимо и как это оптимизировать.
Ну, а для перезаливки всегда можно использовать больше одного спрособа загрузки данных. И самый простой из них - временное отключение консрэйнтов на период заливки.