[quot LSV]//когда-то замерял. Отклонения были в пределах погрешности измерения.

Я тоже. Разница действительно была, если мерять на больших таблицах.

//Navision (по желанию)
Навижн ? Он совершенно не использует никаких механизмов в СУБД (хотя видел пару аццких триггеров). Тем более СЦ. Там вся разработка - исключительно в C/AL. И кстати в базовой конфигурации(!) я запросто грохал из НАВа ключевую запись важного справочника.
Просто элементарно не было обработчика для проверки допустимости удаления. :)

//Чисто из любопытства опишите этот механизм.

LSVУ нас это отдельная ХП с кучей проверок.


Но ХП на "строне СУБД", а Вы вроде были против "стороны СУБД".

На больших таблицах куча проверок быстрей декларативных проверок СУБД?
Как, например, она прверит "уникальность" быстрей СУБД? Разве не выполнит запрос на поиск дублей?

С точки зрения МД ХП разве не проигрывает в выразительности декларативным?

Не говоря уже о затраах на разработку и сопровождение. А ить там должны быть еще и шибки.

LSVЯ не против стороны СУБД. Я против СЦ средствами СУБД для сложных систем.
Тада получается на стороне СУБД, но не средствами СУБД? Но ведь ХП это же средства СУБД?

LSVКуча проверок удобнее. Чем вам поможет глюк при попытке удаления из таблицы ?
.
Глюк - это срабатывание ОЦ? Поможет тем, что не даст удалить, если удаление нарушает ОЦ. Не позволит нарушить целостность данных.

LSVХорошо написанная ХП вполне выразительна и понятна. Все видим в одном месте.

Мы видим код. А с декларативными ОЦ мы видим МД. И например, многие тулсы позволяют нарисовать диаграмму на основе этих описаний в БД. Это более понятно. Ну и есть разница объявить декларация или написать код?

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 тоже что-то не попадалось, в отличии от перечисленных.

[quot LSV]Чихать на них. Бесперспективная экзотика. Не то, что не сталкивался, я даже не слышал. И нет желания.
Отомрут сами за ненадобностью.
[quot ]
Ну Вы же не думаете в серьез, что такого рода аргументы не нуждаются в каких-то дополнительных подтверждениях, очищенных от эмоциональной составляющей?


[quot LSV]Странный вопрос. А зачем для этого отдельные СУБД ? EAV это методика. Не универсальная, но удобная для ряда задач.
Ниодна методика в чистом виде неприменима или неудобна. Всегда используется набор методик и приёмов.
[quot ]
Вопрос был связан с тем, что EAV это не просто методика, а МД. Если нет, НЕ МД, то тада ей тем более нечего делать рядом ООМД. Поскоку последняя МД.

LSVДумаю, не ошибусь, если предположу, что 80-90% прикладных решений не используют декларативную ОЦ. И на это есть много объективных причин.
И не нужно тут тыкать в умные книги. Ок ? Это не более, чем теория или даже (подчас спорное) ИМХО автора. Сферические кони в вакууме. А жизнь сложнее.
Ради хохмы возьмите и приведите свою БД в полное соответствие с 3,4,5 НФ. И что получится ?
Вы можете отказаться и от других достижений технологий БД. Например, от юзания самого СУБД, и говорить про тыканье в умные книги, тем кто их юзает. Сделали шаг: отказались от части важнейших возможностей, сделайте следующий откажитесь от всей СУБД. А эти книги не отрицают достоинств и систем без СУБД кстати, как впрочем и недостатков.
И куда тыкать? В выдумки вчерашних проггеров драйверов, пришедших сеня в БД?
Так я встречал, и тех что на ассемблере всю ИС хотели делать. Ну они системщики до этого были.
Не ради хохмы, но я четко контролирую в каких нормальных формах моя БД. И если какая-то нарушена, то я знаю все последствия. Однако, не помню чтобы БД не была в 3НФ. Я вообще при проектировании следую метологиям рекомендованным в умных книгах. Там этап оптимизации (куда входит и нормализация) схемы обязателен. Мне лишние риски не нужны. Мне не хохм.