OA UserРечь идет о разумном, с моей точки зрения, компромиссе.

Отказ от использования внешних ключей я не считаю допустимым компромисом.

OA UserЕсли проектировщик системы (не хранилища) заранее знает, что при использовании определенного API во всей системе в таблицу не попадут непротиворечивые данные, то зачем ему дополнительная страховка в виде ФК?

И опять у Вас "Если..." не буду повторяться.

авторЕй вполне можно пожертвовать в угоду производительности и прочих вещей.

Замена FK (механизма, работающего на уровне реляционного движка) на самописные провекри на уровне какого-либо API никак не добавит производительности системы. И с этим спорить бесполезно. А вот про "прочие вещи", в угоду которым Вы готовы пожертвовать DRI я готов рассмотреть.

ModelRС одним наверно все согласятся.
Наличие внеших ключей - не гарантия целостности.

Эээ... 100% гарантию дает только бог. ;) Естественно, что если обременный правами человек отключил ограничения для проведения какой-либо затейлевой операции, а потом забыл их включить, или создал их без проверки на соответствие имеющихся данных новому ограничению, то да.

OA UserСпрашивается, что даст наличие внешнего ключа, если пользователь уже авторизован в системе, т.е. ID заранее непротиворечив?

Вы пошутили, или действительно не понимаете, к чему может привести отсутствие контроля ссылочных ограничений?!

OA UserТекущий ID пользователя можно получить легко после авторизации через fnd_global.USER_ID

Можно, никто не спорит. Но кто запретит при написании пакета по недосмотру или злому умыслу взять и удалить из таблички FND_USERS запись о пользователи, который числиться в авторах изменений?! Что будет в этом случаи с "по ID расшифровывается вся информация"?!

OA UserНаличие FK все-таки некий перебор индексных ключей предполагает, не ошибаюсь?

Эээ... Скажем так, наличие индекса на полях, составляющих внешний ключ увеличивает скорость проверки. Впрочем, это поведение аналогично любому другому использованию индекса.

OA UserИ я, кстати, говорил не о замене FK другим механизмом проверки, а об отсутствии такой проверки вообще там, где без нее можно обойтись.

Приведенный Вами пример как раз описывает обратную ситуацию. Проверки нет там, где она должна была быть. :(

OA UserИ таких ситуаций очень много. Кроме того, в зависимости от настроек системы некоторые ограничения могут и не потребоваться вообще. Что с ними делать? Включать/отключать каждый раз? :) По-моему, такого монстра поддерживать не проще будет, чем горы пакетов, пусть и сомнительного качества.

Каких таких?! Если ограничение завасит от настроек системы, т.е. ограничение, зависящее от бизнесч логики, то естественно, оно не может быть реализовано в виде DRI. Здесь помогут, например, триггера. И включать\выключать ничего не надо будет и поодерживается это на раз-два.

OA UserОтчетливо понимаю, к чему может привести, если ДРУГИХ механизмов нет. Я пытаюсь донести мысль, что работа с СУБД и работа с некоей системой, в данном случае OEBS, реализованной пусть на той же СУБД - суть разные вещи.

Я готов бы с Вами согласится, если бы работа с упомянутой системой происходила только на "среднем" уровне, т.е. не имелось бы в принципе возможности обхода ограничений, заложенных на этом уровне. Но на самом деле работа с системой подразумевает ПРЯМОЙ доступ разработчика к хранилищу (через написание пакетов, например, при кастомизации workflow) со всеми вытекающими отсюда последствиями в условиях отсутсвия ограничений.

OA UserПопробуйте это сделать средствами OEBS.

Эээ... Написание пакета в описанном мной выше случаи это разве не "средства OEBS". И что, "это средство OEBS" не даст мне наломать дров?

OA UserЗачем это проверять еще раз?

Что значит "проверять еще раз"?! Проверять надо в одном месте - там где данные храняться, а на среднем звене или классическом клиенте обрабатывать исключительные ситуации.

OA UserМожно попробовать навесить все внешние ключи, перенести максимум логики в триггеры и т.д. Не думаю, что работа типичной OLTP системы порадует Вас своей скоростью.

"Порадует скоростью" по сравнению с чем?! С системой (на уровне СУБД) совсем без триггеров, внешних ключей и т.п. И куда Вы вынесете эту обработку? В среднее звено? И что, при реализации этих возможностей на среднем уровне это не будет уменьшать быстродействие?! Абсурд!!! Рассматривать то надо общую производительность, а не производительность отдельно хранилища. А то по Вашей логике получается, что реализация проверки допустимости корреспонденции счетов или пересчет остатков будет работать гараздо быстрее, если его реализовать не в СУБД, а на среднем звене или совсем на клиенте.

OA UserНе уверен также, что логика, разбросанная по разным объектам базы данных будет поддаваться какому-либо сопровождению.

Гм... Опять позволю себе с Вами не согласится. Вся логика OEBS разбросана по куче пакетов (десятки тысяч), а не на мифическом "среднем" уровне. Такой же подход использую и я при разработке - использование хп (триггеров) для реализации бизнес-логики. Клиенту остается только в нужный момент вызвать нужную хп. И сопровождаются такие (классические 2ву звенки, даже с многотысячным числом объектов) гараздо проще, чем монстроподорбные N-звенки. IMHO.

OA UserВ проектировании любых систем всегда имеет место компромисс, и эта история с внешними ключами - типичный тому пример. Видимо, при достижении определенного уровня сложности в бизнес-логике, требований к производительности, надежности и других критериев такое решение вполне имеет право на жизнь.

Вот уже на протяжении 5ти страниц пока еще никто не привел аргументации, кроме надуманных проблем с производительностью и сложностью системы, которая действительно могла бы полсужить отправным моментом в отказе от использования контроля целостности на уровне СУБД.

OA UserЕще раз попробую объяснить. Дело не в n-звенности системы, а в самом подходе. Система не подразумевает, а допускает прямой доступ к данным, этого никто и не отрицает.

Ды и я об этом говорю, что система "допускает". Ни более, ни менее.

OA UserВы можете писать любые пакеты, процедуры и т.д. , качество работы будет напрямую зависеть от того, насколько вы хорошо знаете структуры таблиц, их взаимосвязи и т.д. Это есть работа средствами СУБД.

И с этим не спорю. Но опять напомню, про заведомые условности при поддержке целосности.

OA UserС другой стороны, можно использовать тот функционал, который предлагает сама система, и который, кстати, она сама в своих формах использует. Например, если в AR нужно загрузить платежи, можно ведь средствами СУБД заполнить соответствующие таблицы, а можно изучить матчасть, заполнить интерфейсные таблицы, вызвать определенный пакет и система сама выполнит необходимые действия. Это есть работа средствами OEBS, те самые "правила игры". И если разработчики системы полагают, что эти правила будут соблюдаться, то они полностью вправе отказаться от ряда ограничений по целостности системы.

Хм... Вы привели пример, где действительно достаточно "уметь пользоваться интерфейсными таблицами", и где возможность наступания на грабли сведена к минимум. Можно привести другой пример, где надо действительно напрямую работать с таблицами (представлениями системы) и уже где возможность наступить на грабли отсутствия DRI возрастает. Я не утверждаю, что это обязательно случится, но спорить с тем, что это может произойти, надеюсь, Вы не будете.

OA UserЯ сам довольно давно занимался разработкой подобного API для системы еще на dbf-файлах, сами понимаете, там пользователя никак нельзя было ограничить, так вот, после перевода пользотельского кода на этот API количество проблем с пользовательским кодом снизилось на порядок, и не потому что я такой мегапрограммист был, а потому, что поведение системы стало прогнозируемым, вот и все.

Не кажется ли Вам, что ограничения на уровне СУБД можно представить тем самым "API", который как раз сведет кол-во проблем с целостностью к минимому? Так зачем тогда он него отказываться?

OA UserПредставьте, Вы отдаете свою систему на сторону, садится там очередной гений, ему неохота разбираться, что там OA User и pkarklin понаписали, он все, что надо, отключает и ваяет свое. Значит, он не будет соблюдать установленные Вами правила, и Вы гарантируете, что Ваша система будет работать?

С дуру можно любой орган человеческого тела сломать. ;) Про 100% гарантию я уже говорил и повторятся не буду. Я просто опять стараюсь сделать упор на то, что и softwarer говорил. Если знаешь место, где можно упасть, то соломки стоит подстелить заранее.

OA UserЯ - больше практик, и для меня надежность системы, грубо говоря, обратно пропорциональна количеству звонков на хелпдеск в единицу времени, и по моему опыту больше всего проблем создавали именно доработки, связанные с нарушением "правил игры", в том числе и триггеры, повешенные на транзакционные таблицы, дополнительные индексы, кривые блокировки и т.д. Проблем, вызванных отсутствием ФК, я не припомню. Посему и делаю вывод, что, как и наличие ФК не является панацеей от всех бед, так и отказ от них является не догмой, а разумным в данном случае компромиссом.

Хм... Спасибо, что отнесли меня к "теоретикам". :) Хотя все выводы, которые я здесь пытаясь привести, из чисто практического опыта. Разумная достаточность должна присутствовать в любом случаи, но существуют моменты, где лично я не готов идти на компромис.


Резюмируя. По-моему, мы уже твердо определили точку зрения каждого из нас, и думаю, что каждый из нас в любом случаи останется при своей.