softwarer EstetsС многими вашими утверждениями согласен, но данное утверждение применительно к блокировочникам буду оспаривать, что называется до последнего
Как раз в этом и состоит моя цель. Надеюсь, на этом примере Вы увидите, что Ваше утверждение применительно к версионникам выглядит столь же... спорно. А следовательно в топике, где ни слова не сказано об используемой БД, нет места ни тому, ни другому.

Я поправился. У меня минимальный опыт работы с Oracle, так что я не могу аргументированно с вами поспорить. Хотя есть все таки сомнения в том что все так просто. Открыл транзакцию - загрузил документ - поправил - нажал ОК commit/нажал Cancel rollback. ;)

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

Тогда стоит наверное сказать на каких типах БД построены данные приложения? Если мы рассматриваем версионники и блокировочники. Или это тоже частный случай применимый только к версионникам?

softwarerРеализация мастер-детали укладывается в считанные строки базового класса "фрейм ввода данных" и позволяет беспроблемно строить сколь угодно сложные иерархии.
Если бы все было так просто, не было бы таких флеймов.

softwarer EstetsВ результате структура кэша усложняется неимоверно, усдажняется соответственно и написание кода по вставке всего в БД.
Хм. Такое впечатление, что Вы говорите о технологиях программирования позапрошлого века. Хорошо написанная сложная программа состоит из множества простых кирпичиков и достаточно проста в реализации.

Ну со своей стороны могу сказать что семейство программ, которые я проектировал используют в 90 процентах три базовых объекта для обработки списка, редактора и фильтра. Уж как говорится объектнее некуда. Но правда связано это с особенностями средства разработки PowerBuider.
softwarer
Согласен, на блокировочнике придется уделить внимание некоторым вещам, которые в версионнике легко решаются. Например, частичный откат - если вы из формы1 вызвали форму2, из формы2 вызвали форму3, в форме3 нажали Ok, а в форме2 - Cancel.
И эту проблему пришлось решать ;)))

softwarerУ меня был проект, где заказчик захотел некий не очень с моей точки зрения обоснованный слой доступа к данным - по сути, грузить данные из БД на клиента, там ими оперировать и так вот кэшированно скидывать обратно.
Возможный подход, но как я утверждаю, применимый только в частном случае. В общем случае требующий неоправданных затрат на проектирование базовых объектов. Настолько неоправданных что я не знаю известных программ, библиотек или средств разработки реализующих данный принцип.

softwarerЯ не знаю PowerBuilder и готов допустить, что на нем все непросто. Насколько я слышал, это продукт с достаточно жестко прописанной идеологией разработки.
Рекомендации по "идеологии разработки" не ограничивают использование своей идеологии. В качестве особенности разработки я имел ввиду технологию DataWindow ээээ некое описание визуального представления для буффера данных (редактор, список, отчет в одном флаконе), что позволяет отвязать проблемы с получением, обработкой и сохранением данных от графического отображения их на экране. Насколько я знаю ничего похожего в других средствах разработки нет.

softwarer EstetsНу со своей стороны могу сказать что семейство программ, которые я проектировал используют в 90 процентах три базовых объекта для обработки списка, редактора и фильтра. Уж как говорится объектнее некуда.
Э-э, очень даже есть куда. Обратите внимание, что названы по сути три визуальных компонента и все.
Именно так и есть, приложение работает как тонкий клиент (вся обработка бизнес логики происходит только на сервере БД. Например настройка пункта главного меню "Список валют" содержит:
имя ХП - для получения данных
имя DataWindow - отвечающей за то как показать данные и как назвать колонки
и имя объекта - отвечающего за показ DataWindow вызов процедуры и обработка действий пользователя (поднятие контекстного меню и пр.)

softwarerЭто более сильное решение, чем "cached updates вообще" и тем не менее реализован без особых проблем. Следовательно и реализовать названное мной [в общем случае] возможно и не слишком сложно.
Нет действительно если для работы с ORACLE достаточно "Открыл транзакцию - загрузил документ - поправил - нажал ОК commit/нажал Cancel rollback. ;)", то я первый побегу с требованием к разработчикам сменить БД ;) и не напрягать службу поддержки дурацкими вопросами почему в отчет попала паразитная запись.

softwarerХм. То есть Вы считаете две тысячи строк неоправданными затратами?
Не знаю. Лично я готов потратить неделю-две, дабы потом год за годом беспроблемно работать.
Как говорил классик "Не верю", именно из за того что представляю объем необходимого кода и не представляю всех засад которые могут возникнуть при его реализации.

softwarerХм. Какой именно принцип? И если на то пошло, какие Вы знаете? :)
Если упростить до предела "Нельзя создать связанную запись до тех пор пока главная запись физически не сохранена в базе". Из чего следует ;) что не существует промышленных систем реализующих в полном объеме как вы сказали "cached updates" обновление информации для документов MASTER-DETAIL.

Ладно, пойдем попорядку ;)

Есть форма реализуюшая отношение Master-Detail. Оператору необходимо сохранить 1 главную запись и N подчиненных. Можно

А. Открыть транзакцию, добавить запись в БД дать пользователю ее редактировать, добавить подчиненную запись в БД дать пользователю ее редактировать (N-раз). При нажатии кнопки ОК закоммитить транзакцию, при нажатии кнопки Cancel откатить транзакцию. Временных записей в БД не возникает.

Б. Добавить запись в буффер (DataSourse, структуру, массив в зависимости от используемого ПО) дать пользователю ее редактировать, добавить подчиненную запись в другой буффер, дать пользователю ее редактировать. При нажатии ОК открыть транзакцию, рекурисвно обойти все буффера сохраняя записи в БД, если нет ошибок закоммитить транзакцию. Временных записей в БД не возникает.

В. Добавить запись в БД дать пользователю ее редактировать, добавить подчиненную запись в БД дать пользователю ее редактировать (N-раз). Если пользователь завис то он должен сам удалить эту запись иначе эту запись нельзя отличить от отредактированных.

Г. Добавить запись в БД помеченную как временная, дать пользователю ее редактировать, ... для перечня, при нажатии кнопки ОК обновить состояние записи на актуальное.

Ну теперь итого:

А - возможно только для ORACLE
Б - возможно для версионника и для блокировочника, но в сложных случаях ИМХО не реализуемый
В - способ известный еще со времен DBASE, имеет право на жизнь, и достаточно часто используемый во всяких Axapta подобных системах. Но череватый паразитными записями.
Г. - предложенный мной способ решения, имеющий свои особенности.


softwarerХм. Что-то я перестал Вас понимать. Я тоже не знаю библиотек, реализующих столь идиотский принцип, и не понимаю, откуда Вы его вытащили. Если же говорить о принципе "нельзя сохранить связанную запись, пока главная не сохранена", то он называется FOREIGN KEYем, и построенных на его учете библиотек, назовем так, много :)
Мое утверждение касалось варианта Б. И еще раз могу сказать, что я не видел программ его реализующего в полном объеме.

Забыл кстати еще один способ

Д. Не давать пользователю вносить перечень пока он явно не сохранит главную запись. Что тоже мной использовалось для сложных но редких настроек.

Один1Мне кажется, вы не совсем понимаете что есть версионник и блокировочник. Советую почитать например здесь http://www.ibase.ru/devinfo/versions.htm
Спасибо, я человек простой, от сохи, по этому повду знаю только одно что если человек открыл транзакцию и обновил одну запись в таблице и забыл ее закрыть, то рано или поздно на уши встанет болшой отдел ;)

softwarer EstetsСпасибо, я человек простой, от сохи, по этому повду знаю только одно что если человек открыл транзакцию и обновил одну запись в таблице и забыл ее закрыть, то рано или поздно на уши встанет болшой отдел ;)
В случае Оракла - столько не живут :) Во всяком случае лично я за скоро десять лет работы с сервером ни разу не видел отдела, вставшего на уши по этому поводу.
Так это все таки заслуга Oracle без его блокировки ресурсов при изменении данных или ваша? ;))))

softwarerНе знаю, что Вы называете полным объемом. В моем последнем проекте таким образом идет работа с метаинформацией проекта. Там есть понятие "ядро" - на текущий момент это системная часть клиента в двухзвенке, в перспективе также будет промежуточным звеном в трехзвенке; это ядро при старте грузит в себя метаинформацию, позволяет ее редактировать и по кнопке "сохранить" сбрасывает изменения в БД.
Разработка больших проектов требует схожих решений, у нас тоже использовались термины ядро и метаинформация ;) В нашем понимании ядро включало в себя
"Ядро документооборота" - работа с документами, статусами документов, гафом переходов между статусами. Которое в том числе содержало метаинформацию о полях, таблицах, процедурах.
"Ядро настроек беропасности" - соответственно роли пользователи и допуска к документам, состояниям и пр.
"Ядро учета" - базовый механизм внесения проводок, планы счетов, счета, периоды, шаблоны для получения остатков и оборотов.

А по поводу возможности реализовать алгоритм "Б", я не говорил что это невозможно, я и сам часто такой подход использовал, но полностью построить систему по такому принципу у меня мозгов и времени не хватило ;)

Могу рассказать одну грустную историю. Есть простейший документ, допустим "строка перечня приходной ведомости на склад" при обработке накладной нам необходимо сделать проводку по складскому плану счетов с датой, количеством, и аналитикой по товару. Причем все эти данные есть в документе.
Вызывается ХП копотая обходит перечень накладной и делает проводки, примерно такого текста


Реальный код не слишком сложнее приведенного, но чтобы человек смог настроить/изменить проводку он должен знать TransactSQL ;-0.
Начальство решило с этим бороться, а давайте сказали они для документа сделаем настройку проводок, типа простой пользователь выберет счета, поля документа, из которых брать сумму, валюту, аналитику и пр. и все будет в шоколаде.

Сделали. Часто из суммы надо вычленять НДС, сделали, всякие курсовые разницы распределяются на разные счета в зависимости от знака, сделали проверку условий проводки. Балансовая стоимость списывается по партиям, сделали поддержку LIFO-FIFO. Есть проводки по нескольким суммам, написали возможность расчетов в полях. Есть зависимые проводки, развернули настойку в дерево.

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

Один1 EstetsВ результате проблему решили, но затраты на настройку всего этого, и вероятность совершения ошибки превышают выгоды использования данного механизма. А пользователи этим механизмом пользуются ? Или все равно говорят программисту "добавьте мне, пожалуйста, проводку" ?
Были продвинутые пользователи которые на SQL что то дописывали. А в данном случае не все программисты в конторе понимают как это работает, только избранные ;))

softwarerЗнаю. Делали подобную вещь. Сделали так: во-первых, вычленили ключевые, часто используемые вещи и сделали их на уровне настроек. Во-вторых, предусмотрели в конфигурационных таблицах "гнезда", куда можно написать скрипт или имя хранимки - на случай редкой особенности, которую невыгодно таким вот образом универсально автоматизировать. Наконец, я написал программу для редактирования и верификации этой метаинформации. Программа достаточно сложного интерфейса, не для простого пользователя, но использовал ее собственно эксперт-настройщик. Отзывы были весьма положительные - то есть пользовались, просили доработок и вплоть до "приехал к клиенту и прямо по ходу беседы подстраиваешь то, что обсуждаете".
Может быть это и выход, но у нас такой возможности не было. Логика была только на сервере и соответственно закладывалась в момент компиляции процедуры или работала по настройкам, которые выполнялись скопом и вмешаться в процесс выполнения было нельзя.

softwarer EstetsМожет быть это и выход, но у нас такой возможности не было. Логика была только на сервере и соответственно закладывалась в момент компиляции процедуры или работала по настройкам, которые выполнялись скопом и вмешаться в процесс выполнения было нельзя.
Хм. А в MSSQL-е отсутствует динамический SQL?
Гы гы гы, есть то он есть да ктож ему даст. В смысле права для пользователей напрямую изменять таблицы, а иначе все это сильно не помогает.