Гхостик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 СЦ тормозит . Дико мешает перезаливать данные (иногда это нужно).Потому и нужно внимательно думать, где это действительно необходимо и как это оптимизировать.
Ну, а для перезаливки всегда можно использовать больше одного спрособа загрузки данных. И самый простой из них - временное отключение консрэйнтов на период заливки.

Кот МатроскинИ что помешает записать в этот атрибут ссылку на Entity другого типа?Бизнес-логика? Валидация в интерфейсе пользователя?
Кот МатроскинForeign key пропустит - вполне валидная ссылка на Entity, никаких проблем.Потому как это и есть "ссылочная целостность"...

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

ЗЫ. У внешних ключей есть еще одна явная польза - легко восстанавливаются логические связи между данными в базе.

Кот Матроскинsphinx_mvпропущено...
Бизнес-логика? Валидация в интерфейсе пользователя?

Именно это я и назвал "промежуточным API"Если подходить с этого ракурса, то даже банальная вставка данных в EAV-базу тоже выполняется через "промежуточное АПИ"...
Кот Матроскина валидация в интерфейсе пользователя - это вообще ни о чем, в мою текущую систему 99% данных приходят минуя какие-либо интерфейсы пользователяЭто ничего, что "пользователем" системы может выступать какой-нибудь программно-аппаратный автомат, который тупо льет данные в базу через "пользовательский интерфейс", представленный некоторой вьюхой или хранимой процедурой?
Кстати, такие варианты очень часто рассиматриваются при лицензировании серверов баз данных.
Кот Матроскинsphinx_mvПотому как это и есть "ссылочная целостность"...
Ну да, когда родителем ребенка можно указать в базе автомобиль КАМАЗ или фирму "Ромашка" - это ж отличная ссылочная целостность, непонятно что еще нужно :)Ну, это на самом деле элементарно!
Вот, что сайтопейсатели какого-нибудь "ынтырнет-магазина" позволяют выбрать в форме при заказе, и что родители ткнут в этой самой форме, такой "паровоз" ребенок и получит - EAV тут при чем?! Чистая "бизнес-логика", будь она неладна... :)

Dimitry SibiryakovLSVЗато процедура может решить ВЕСЬ спектр задач сохранения данных
За исключением одной: поддержания собственно ссылочной целостности в многопользовательском
окружении без эскалации эксклюзивных блокировок на всю БД.
Тут бы еще про "версионники" вспомнить...

ChA(поскипано по причине много букв)Надеюсь, в метаданные (любого) SQL-сервера Вы заглыдывали...

ChAsphinx_mvпропущено...
Надеюсь, в метаданные (любого) SQL-сервера Вы заглыдывали...Это вопрос или аргумент ? Может попробуете ещё раз ?Это был намек... Но если Вам этого намека (и ОЧЕНЬ прозрачного) было не достаточно, могу и разжевать...

Вывод на основе Ваших утверждений: сервера баз данных проектируют неофиты... В базах данных есть структуры для хранения метаданных... Там же есть структуры для хранения данных... И есть даже некоторое API, которое на основе метаданных представляет данные как объекты реляционной базы. Итого, на выходе - "универсальная модель данных, на которую с легкостью натягивается любая сколь угодно кривая и ненормализованная модель данных предметной области(ПО), используемая в качестве серебрянной пули" (с) не буду показывать пальцем чей.

И сугубо на основе Вашего скромного мнения, Вы не вполне адекватно представляете себе ни реальной пользы, ни возможностей, ни границ применимости EAV в базах данных - поэтому Вы считаете, что оно неприменимо. Проблема в том, что оно неприменимо для Вас - это зависит только от задач из Вашей сферы деятельности. А на самом деле "в мире" существуют области, где EAV-модель является не только подходящей, но и подходящей идеально . В качестве простого примера - база данных, обслуживающая RADIUS-сервер, протоколы которого, связанные с аутентификацией, авторизацией и аккаунтингом, состоят из запросов на основе наборов пар "атрибут-значение".

ЗЫ. То, что избыточная нормализация приводит к возникновению структур данных, эквивалентных EAV, оставляю Вам для самостоятельного практического исследования на досуге.

guest_20040621EAV - костыли, оправданные в ограниченном количестве случаев.Если Вы настолько умный, Вам следовало давным-давно хотя бы попытаться узнать, что любой принцип проектирования применим в достаточно ограниченном количествое случаев. И очень редко без разумного сочетания разных принципов получается более/менее удовлетворительный результат.
guest_20040621Это не нужно обсуждать, это нужно запомнить.Ну, так и запомнните. Вам это кто-то зарещает?
guest_20040621> В базах данных есть структуры для хранения метаданных...
Вас жестоко обманули. В СУБД есть структуры для хранения метаданных. И никакого отношения к EAV они не имеют.У Вас разрыв шаблона, потому что "там оно так не называется"? Бывает...
Таблицы метаданных, которые описывают правила представления массивов байт в виде таблиц с определенным количеством полей оределенного типа данных... Функционально - близнецы-братья/сестры...
guest_20040621Любая метамодель описывается посредством, например, MOF, которая тоже никакого отношения к EAV не имеет. Здесь тоже нечего обсуждать.EAV - принцип, а не конкретная реализация, которых может быть множество.
guest_20040621> база данных, обслуживающая RADIUS-сервер
Который в общем случае вполне может обойтись без базы данных.А чего Вы скатываетесь в "общий случай"?
Указан вполне конкретный. Или слишком "острые" не могут отличать "общее" от "частного"?

Не понятно, для чего Вам вообще базы данных для "общего случая"?
Счеты, бумага, карандаш - и вперед учитывайте, ничем особо не заморачиваясь.

ЗЫ. guest_ 20040621 ...
2004-06-21 - это памятная для Вас дата чего? Рождения?

ChAsphinx_mvпропущено...
Это был намек... Но если Вам этого намека (и ОЧЕНЬ прозрачного) было не достаточно, могу и разжевать...

Вывод на основе Ваших утверждений: сервера баз данных проектируют неофиты... В базах данных есть структуры для хранения метаданных... Там же есть структуры для хранения данных... И есть даже некоторое API, которое на основе метаданных представляет данные как объекты реляционной базы. Итого, на выходе - "универсальная модель данных, на которую с легкостью натягивается любая сколь угодно кривая и ненормализованная модель данных предметной области(ПО), используемая в качестве серебрянной пули" (с) не буду показывать пальцем чей.Вынужден констатировать, что с логикой у Вас те же проблемы, что и со знаниями. Ещё раз, нормализация не имеет никакого отношения к EAV, она применима к РМД. Как бы сам EAV не был нормализован в терминах РМД, это не переносится автоматически на ту модель данных, которую натягивают поверх него.Слов-то сколько! И куча ляпов в "посылах"...
"Модель данных"... "модель данных"... В EAV модель описывает способ хранения и доступа к данным - и ВСЕ! Хоть на ассемблере описывай!
А собственно про данные что промантровать сможете? Вот только терзают смутные сомнения в Ваших "возможностях"... Подсказка: ДАННЫЕ атрибутов сущностей в EAV хранятся в ОЧЕНЬ СИЛЬНО нормализованном виде с использованием реляционной модели. ДАННЫЕ!
"Нормализация не имеет никакого отношения к данным, хранящимся в реляционной модели" (с) ChA - это стопудово в анналы...
Прикол в том, что "нормализация по сути" имеет отношение еще много к чему, кроме реляционной модели данных в СУБД.
ChAsphinx_mvИ сугубо на основе Вашего скромного мнения, Вы не вполне адекватно представляете себе ни реальной пользы, ни возможностей, ни границ применимости EAV в базах данных - поэтому Вы считаете, что оно неприменимо. Проблема в том, что оно неприменимо для Вас - это зависит только от задач из Вашей сферы деятельности. А на самом деле "в мире" существуют области, где EAV-модель является не только подходящей, но и подходящей идеально . В качестве простого примера - база данных, обслуживающая RADIUS-сервер, протоколы которого, связанные с аутентификацией, авторизацией и аккаунтингом, состоят из запросов на основе наборов пар "атрибут-значение".К сожалению, с телепатией у Вас ещё хуже, чем с вышеупомянутым. О EAV я знаю достаточно, так как сам с ней работал и до сих пор имею дело . И прекрасно знаю все её минусы. С плюсами сложнее, их почти нет.Я уже затрудняюсь определить, с чем у Вас проблемы, но пример использования EAV, которое полностью раскрывает плюсы и совершенно игнорирует все минусы, был приведен. Кроме пустопорожнего растекания мыслею по древу Вы ответить ничего не смогли - что, как бы, намекает.
ChAС чтением, по ходу, у Вас тоже проблемы. Напомню, эта модель представляет интерес только "для решения конкретных узкоутилитарных задач". Не более того. В остальных случаях, она играет роль ненужного костыля и оправдывается обычно только незнанием предметной области. Каждый неофит проходит через стадию увлечения EAV, но некоторые так и остаются в заблуждении, что это вершина проектирования БД.Зато у Вас наблюдается не просто ноль с логикой, а отрицательная ее величина... Немеряно пафоса... "Все неофиты"... "Использовать EAV нельзя нигде"... И выделенное красным заставляет ОЧЕНЬ сильно задумываться, к кому Вас отнести... Кстати, в каком месте я говорил о чем-то ином, кроме некоторых вариантов использования Вы тоже придумать так и не смогли... Бывает... Соответственно, у кого проблемы, не считая логики, с чтением - вопрос интересный... Суметь прочитать то, чего не написано - это сильно!..
Но ладно... Расслабьтесь... Считайте, что Вы теперь - Д'Артаньян. Вот только, чтобы быть Д'Артаньяном не достаточно носить белые перчатки.
ChAsphinx_mvЗЫ. То, что избыточная нормализация приводит к возникновению структур данных, эквивалентных EAV, оставляю Вам для самостоятельного практического исследования на досуге.Встречное предложение: вместо фантазий попробуйте почитать на досуге что-нибудь про нормализацию, например - Дейта, может попустит. Хотя есть опасение, что не в коня корм.Похоже, Дейта Вы только на обложке и читали... Но зато знаете "цвет учебника" - на твердую троечку потянет...

guest_20040621Идиоты типа вас не удивляют.Просто рекомендация: отодвиньтесь от зеркала и выключите компьютер - становится слишком очевидно, про кого Вы пишите...

guest_20040621sphinx_mv, дружище, именно метла. Не занимайтесь проектированием, вам это противопоказано. И, пожалуйста, не пишите здесь ничего. Мне не доставляет удовольствия называть баранов баранами, даже если они этого заслуживают.Рекомендация Вам хотя бы отодвинуться от зеркала действия не возымела...
Жаль, а то мало ли еще кого Вы в зеркале в Вашем-то состоянии способны увидеть...

SERG1257sphinx_mv но пример использования EAV, которое полностью раскрывает плюсы и совершенно игнорирует все минусы, был приведенА вот я не знаю как RADIUS работает с БД. Почему именно EAV.Приведу пару примеров не самых сложных RADIUS-пакетов - всего лишь диалапный аккаунтинг ( взято тут )...
Кроме аккаунитинга (навскидку) есть еще аутентификация и авторизация с прописыванием параметров соединения, c динамической маршрутизация. И с RADIUS-протоколом работают не только по диалапу. Количество атрибутов и их типов зависит от вида услуги. Кроме этого возможно использование атрибутов, определяемых производителем оборудования. В одном пакете может быть несколько десятков пар "атрибут-значение" - и количество не постоянно, и для некорых атрибутов допускается повтор.

"Плоскую" таблицу с зарезервированными под каждый атрибут полями использовать? По самым скромным оценкам, примерно полей, этак на 100... И большая часть из из этих полей - "строки".
По отдельной таблице под каждый "чих моды" вид сервиса, под каждого "отдельно взятого" производителя и под каждый "отдельно взятый" тип оборудования? Чтобы "оценить последствия": список словарей одних только вендорских атрибутов, которые поддерживает небезызвестный freeradius , приближается к двум сотням штук...
Так что, EAV - и не париться!

ChAsphinx_mv...Мне жаль, что Ваша воинствующая глупость была ошибочно принята мною всего лишь за заблуждение.Это Вы так завуалировано именуете Вашу неспособность вменяемо излагать свои мысли?
А Вы точно уверены, что хоть какие-то мысли у Вас были?
ChAК отсутствию у Вас упомянутых ранее положительных качеств добавились сугубо отрицательные, как-то активное враньёО, как! И это я, оказываеся, с враньем тут засветился... А цитатку не слабо?
ChA и безудержная, высосанная из пальца, чушь.Ваша? Факт!
Вы ее придумали. Вы ее приписали оппоненту. Вы начали с пеной ее опровергать. Справшивается: кто кому ССЗБ?!