pkarklin ModelRНу и как должно выглядеть самодостаточное бухгалтерское хранилище? Чтобы в базовой функциональности изменение счета в проводке
- контролировалось по правилам корреспонденции счетов,
- вызывало изменение сохраненных остатков,
и др.

Эээ... Я не совсем понял, что Вы хотите услышать от меня в ответ на Ваш вопрос?! Речь в топике шла о DRI.

ModelRС точки бухгалтера все эти грехи ничем не лучше битой ссылки на счет.

Эээ... Опять не понял, контроль корректности корреспонденции - это бизнес-логика, которая просто обязана пристутствать в системе, в прочем как и пересчет остатков. А Вы говорите о каких-то огрехах. И, опять же я не вижу, каким образом ее (бизнес-логики) присутствие в том или ином виде потребует отказаться от DRI?!

ЗЫ. Возможно, я все-таки не понял, что Вы хотели сказать.
Сорри за поздний ответ, но возможно еще интересно....
Мысль в том, что RI - часть бизнес-правил, бизнес-ограничений в целом, причем по объему - очень небольшая часть. С точки зрения ERP нарушение RI ничем не отличается от нарушения корееспонденции счетов - транзакция отвергается. Так зачем размазывать контроль бизнес-ограничений: проверять RI через DRI в СУБД, а корреспонденцию - на сервере приложений? Тем более, что реакцию на эксепшион СУБД все равно нужно как-то обработать в приложении.
Ну будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.
Так что архитектура с отказом от ФК в СУБД вполне логична, если существует слой контроля бизнес-ограничений в приложении.

softwarer ModelRТак зачем размазывать контроль
Потому что для надежности решения крайне рекомендуется проверять везде, где только возможно и не слишком напряжно. И из занятий репликацией, и из других работ я вынес простой принцип: проверок много не бывает. Также, надеюсь, Вы согласитесь с тем, что для столь масштабного проекта надежность каждой детали имеет значение "выше среднего".
.Чем плохи общие рассуждения? Их легко довести до абсурда :). Для надежности может и проверку CRC всюду собственную засандалить. softwarer
По сути, Вы говорите примерно следующее: если LookupComboBox не способен выбрать запись, отсутствующую в справочнике, делать внешний ключ на этот справочник необязательно, все и так будет хорошо. В чем-то это верно, но на практике рано или поздно вылезет проблема, например при удалении из этого справочника.Нет, я говорю, что удаление - также операция среднего слоя, и он проверяет все бизнес-правила, связанные с удалением, включая наличие ссылок на удаляемый объект. ФК СУБД в этом случае греет воздух вхолостую - проверяет уже проверенное. Его единственное назначение - а вдруг кто пойдет в обход? - но не будем повторяться.
Кстати, даже удаление может быть связано с логикой, не доступной DRI. Скажем, если ссылающийся объект "дешевый" - то CASCADE его, а иначе RESTRICT. softwarer
ModelRНу будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.
По этой логике мыться бессмысленно, потому как в итоге все равно умрешь. Нужно проверять и то, и другое, и третье. Есть возможность проверить это "третье" исключительно дешево и надежно. И отказываться от этого - примерно так же оправданно, как прыгать с парашютом без запаски.
Не внимательны, коллега. Вопрос не нужно/ненужно, а где проверять и сколько раз. Следуя Вашим примерам - Иногда нужно все-таки выходить из-под душа. А если повесить десяток запасок, боюсь будет тоже, что не брать парашют вообще.

iscrafm ModelR , спрогнозируйте поведение системы на рисунке ниже. В различных ситуациях, в зависимости от того, кто первый стартанет транзакцию. Ведь практически все называют множество серверов приложений в качестве средства масштабирования, и это нормально. Вот только с целостностью данных (не путайте с правильностью транзакций с точки зрения бизнес-логики)А как не путать-то? Что СУБД по счастью умеет декларативно - это целостность, а остальное - не целостность? iscrafmв этом случае нужно что-то делать. Иначе и через рекомендуемый API такого понаделают. Или будете играться уровнями изоляции сводя на нет достигнутую таким образом производительность?
В вашем примере через аппсервер выполняется нативный кода СУБД. по сути это работа в обход аппсервера. Результат ИМХО тот же - 95% бизнес правил остаются без внимания.
Или я чего-то не понял?

iscrafmЕсть отличие между неправильной транзакцией (исправимо) и безадресной транзакцией. Вам о чем-то говорит платеж клиента {90676D43-82AD-11DA-947D-0020ED19160F}? Или так - CST00128, если суррогатные ключи не любите.Не понял разницу. Безадресная исправима проставлением нужного адреса, или добавлением адресата - смотря как понять"безадресная". Вот скажите, правило "Структура изделия не содержит циклов" это разве не целостность данных? Или пока соотвествующая кляуза не появится в SQL - оно и не целостность? iscrafm
Сервер приложений с БД в конечном итоге общается на понятном ей языке. Я привел пример конечного итога, упустив моменты, каким образом этот код образовался. В данном вопросе это не важно. ИМХО важно. Скорее всего этот код будет частью некоторых транзакций, которые будут содержать блокировки и проверки, что и обеспечит целостность.
Насчет как блокировать тут коллеги по соседству бодаются . И если аппсервер имеет собственный механизм блокировок, то они просто не видимы для СУБД и тут даже ФК не спасет при работе мимо приложения.