LSVРазница есть.
Как узнать в некотором фрагменте кода, что там может сработать некая декларация ?
Никак. Нужно руцями полесть в тулзу и зачитать наличие или отсутствие таковой. И так каждый раз.

Декларация - противопоставляется коду: она не в фрагменте кода.
В частности, она в словаре БД. Т.е. с помощью декларативных же запросов можно посмотреть все ОЦ. И это сделать может тулса по проектированию БД, и нарисовать диаограмму. Например, ERwin.




LSVКстати этим же неудобны триггеры. Их нужно смотреть в другом месте.

Тригерра это ХП. И место просмотра играет, скорее всего, меньшую роль, чем что смотреть: код или объявление.

Но раз Вы к триггерам так относитесь, то у Вас проверяющую ХП вызывает клиент? Но БД в силу природы весчей предназначена для многих программ. Я намекаю, что админ или кто-то может залезть не стого клиента, и проверяющая ХП не запустится.

LSVу Вас проверяющую ХП вызывает клиент?Нет. Ее вызов вставлен в другую ХП. Вся работа происходит только через ХП. Поэтому, дёргая ХП, невозможно вывести систему из целостности.

Ну а кто вызовет эту "другую ХП"? Я намекаю, что это ничего не меняет та или другая но все равно ХП. Ее кто-то должен вызвать. Раз не триггер ее вызывает, то кто?

Кроме того, Вы как-то не прояснили вопрос с декларативными ОЦ. Т.е. которые моно просто объявить? Не в каком ни в коде.
Если ОЦ не удается навязать декларативно, тогда триггер.
Но целосность отношения (уникальность), СЦ и ограничения на значения можно навязать декларативно.


Есть, возможно, ситуации када сложные БП не совсем типа ОЦ. Например, это разные правила для разного персонала. Ну тада тока ХП или вообще на стороне сервера приложений или клиента.

LSVНамёк не понят. Что не меняет ?

Как раз наоборот, ничего не меняет: как устроена ХП не имеет значения. Вызывается из клиента: детали ХП ниче не меняют.
У Вас ОЦ из приложения контролируются.

А доступ к БД возможен, например, с административных клиентов, которые не вызовут этих ХП. Тогда как триггеры и декларативные ОЦ сработают.

LSVПроверяющая ХП является единственной точкой всех проверок любой сложности в этом документе/справочнике.

Показать все деклараттивные ОЦ моно одним запросами, что луче всяких точек и кода.
Да и триггера тока вызывают ХП. Моно опять разрабатывать чтобы удобно смотреть было.


LSVРеализовать такое на триггерах и констрайнтах может и возможно, но это месиво из кучи трудноуправляемого кода и настроек в разных местах.

Наверное, Вы констрайнтами называете ОЦ, которые моно объявить. Но на самом деле констренты это ОЦ. Декларативные, триггерные и те что Вы пытаетесь реализовыавть из приложения.
В любом случае Вы отказываетесь от достижений технологий БД.
Там МД - фундамент, а Вы ОЦ выносите на уровеннь приложения, хотя и храните код в БД. Но поскоку без приложениях ОЦ нет, то к МД их не отненсти. Возможно, для встроенных БД это и ниче, но када клиентов много это шанг назад к файловым системам (то что было до БД для таких задач).

Буржуа создали СУБД, способные поддерживать важнейшие для РМД ОЦ декларативно, и триггера для остальных, а Вы это не юзаете. Т.е. не используете важных возможностей СУБД. Зато пишите свой код для этого же, т.е. конкурируете в этом с производитенлями СУБД, а не студентами их юзающими. Т.е. даете этим студентам фору, поскоку превзойти производителей СУБД в этом все еще проблематично.

MasterZiv При этом делает он средствами
обычной реляционной модели, никуда за её рамки не выходя.
Поэтому ничуть ничего не выворачивается.

Но это как раз можно увидеть выворачивание: средства от другой (РМД) МД прикручены к EAV.
Ожидались свои средства.

MasterZiv
Преимущество в EAV одно -- можно динамически создавать новые атрибуты
сущностей.

Возможно, за счет того, что эти самые атрибуты по сути превращены (вывернуты) в данные.
Ну а данные в РМД можно менять.
Это преимущество слабоструктурированных МД перед сильно структурированными.
По взрослому это пытаются решить с помощью соотвтующего типа МД, например, XML.
Ну типа там и средства свои.

MasterZivНедостаток -- большая сложность работы с данными.

Ну правильно, средства РМД (манипулирование, ОЦ ) расчитаны на соответсвтие струтуры МД структуре предметной области.
А струкура EAV (таблицы и атрибуты) далеки от этого в общем случае. Имена атрибутов из EAV в SQL не подставишь. Декларативные ОЦ не навяжешь.

Конечно, на практике возможны компромисы (недостатки слабо проявляются, а атрибуты не известны заранее для какой-то части БД), но на идеальное EAV вряд ли претендует.
Ей бы тада, скорее всего, подошли специальные какие-то свои средства а не от РМД.

LSVна идеальное EAV вряд ли претендует. Не претендует. Идеалов пока не существует.

А собственно, кто претендует ?
Ну извините, по сранению не тока с РМД, ООМД, ХМД, но даже там с иерархическими образца 1970 года, она, скорей всего, смотрица в заду. Она, скорей, как вынужденная затычка для РМД в некоторых ситуациях имеет смысл.

LSV1. Что такое ХМД ?
Опечатка. Имелось в виду XML (буквы Д и L на одной клавише, вот и ошибся)

LSV2. А сами ООМД разве не в заду (если мы обсуждаем СУБД) ?

Ну даже если ООМД в заду, то EAV в значительно большем. Так или иначе ООСУБД есть: Версант, ГемСтоун или типа того. Да и всякие стандарты и проч. А EAV СУБД хде? РСУБД в EAV не переименуется из-за того что там кто-то налабает три таблы и назовет это EAV. Да и сами же видите, что средства от РМД. Вы их и не юзаете: ХП пишете вместо декларативных ОЦ. Ну что это за МД?
В толстых книгах про EAV тоже что-то не попадалось, в отличии от перечисленных.