Кот МатроскинИ что помешает записать в этот атрибут ссылку на 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 - и не париться!