Ответа на вопрос, зачем, как и в каких случаях подобные задачи решать, четкого и однозначного нет. Как вы "перепроведете" документы, в которых цена ранее уже была посчитана, документы выданы на руки клиентам и эти клиенты разъехались по странам и весям?
Когда-то Дед Маздай на форуме по MS SQL Server приводил байку про девушку, которая по ошибке сунула конверт с деньгами в шредер, и теперь ей нужно этот конверт с деньгами восстановить... Задача примерно такого же плана... :)
Откатить, перепровести, переделать - всё это можно только в определенных рамках. Вообще же жизнь изначально устроена так, что "дважды в одну реку войти не получаится". Поэтому каждый в каждой конкретной ситуации думает, как можно из нее выкрутиться (если можно) персонально-индивидуально. Запускать же алгоритмы, которые будут оценивать "обратимость" или "перепроводимость" операций - это все равно, что пытаться сотворить Землю в 3 дня. И никакие "постреляционные СУБД" решить задачу вталкивания в принтер уже распечатанной накладной с превращением ее в чистый лист - ну не помогут... :) ПМСМ.

sobolevИнтересный пример, который хотелось бы примерить к Вашей системе. Счета выписываются только в том случае, если размер маржи не ниже 10%. Клиент звонит и просит выписать счет на товар. Система проверяет - маржа 10.2% на грани, но в пределах заданного значения. Счет выписан, товар оплачен, получен, счета-фактуры, пятое-десятое...
Потом задним числом вводится приход или расход, который перераспределяет партии приходного товара, полученные по разным ценам. И оказывается, что маржа по ранее выписанному и уже оплаченному счету уже не 10.2%, а -2% (вообще убыток!). Караул! Нельзя было, оказывается этот товар по такой цене продавать, нужно было дороже! А его не только оплатили, но уже и отгрузили!
Теперь, собственно, вопрос. Что Ваша система сделает:
1. Не даст ввести приход (или расход) задним числом, который, тем не менее, реально имел место?
или
2. Вернет деньги покупателю и заставит его вернуть товар?

Прошу понять меня правильно. Я не имею намерения Вас обидеть. Просто озвученная задача ДЛЯ ОБЩЕГО СЛУЧАЯ каким-то унифицированным способом принципиально не разрешима. Используемый Вами принцип реализуем во многих системах, но он далеко не всегда и далеко не всех может удовлетворить.

Uncle_AlexРечь не шла об изменениях параметров документа введенных непосредственно оператором. Имелась в виду себестоимость/цена списания, которая извлекается системой самостоятельно. Вот она то при вмешателство в прошлое и может оказаться не актуальной для более поздних по оси времени операций.В примере, который я привел чуть выше, как раз о цене списания и идет речь. Она может измениться, если добавить задним числом еще один приход или расход, стараясь при этом соблюсти принцип FIFO (или LIFO). Если "на лету" по ценовым параметрам принимаются какие-то принципиальные решения (как я привел выше), то любое перепроведение задним числом может потребовать пересмотра этих решений. Если ничего "на лету" не считается, никаких решений не принимается, то нет вообще смысла сразу проводить документы. Нужно их сначала ввести, а потом все скопом один раз провести - в конце месяца, например.

sobolevКстати, сказать, пересчет итогов (у нас это называется "форвардные остатки") не очень сложная проблема. Это требование было сформулировано до начала разработки системы (1996).Вас не затруднит ответить на вопросы, которые я задал выше? После Вашего ответа станет более-менее понятно, смогли ли Вы разрешить те проблемы, за решение которых Гликоген и предложил давать Нобелевскую премию (может быть, не совсем внятно).

iscrafm Uncle_Alex iscrafmЕсли требуется актуализация real-time, нужно выбирать что-либо из версионников, безблокировочников, in-memory и т.п.
Прошу простить мне мою дремучесть, а что это такое? Можно что нибудь конкретное для обзора.
Транзакция читает данные, изменяемые в это время другой транзакцией. В блокировочнике она ждет завершения, в версионнике - читает данные зафиксированные до начала второй транзакции. Т.е. читатели не ждут писателей. In-memory - таблицы размещаются в памяти. В двух словах. Поиск в интернете даст много информации.Ну, не всё так просто. На самом деле каких-то существенных отличий между версионниками и блокировочниками нет. Ждет или не ждет блокировочник, может зависеть от уровня изоляции транзакий. Если "грязное чтение" разрешено, то он может и не ждать. С версионником - аналогично. Если версионник не ждет, значит он рискует получить несогласованные данные. Если контроль согласованности данных отрабатывается в триггерах, то на уровне версий данных для параллельных транзакций могут получиться согласованные данные, а при записи версий этих транзакций в единую базу данных они все равно окажутся несогласованными. Это "болезнь" версионников.
Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2.
На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике.

Uncle_AlexНу не скромничайте сказавши А скажите Б. Интернет могучая сила, дай те хоть название СУБД отражающие приведенные тенденции. С читающей транзакцией Вы меня просто озадачили. Я всегда под термином "транзакция" понимал алгоритм связанный с модификацией данных??? Заранее благодарен за источники.MS SQL Server - блокировочник (хотя начиная с версии 2005 там появилась возможность выполнения транзакций в стиле версионника). Oracle - версионник, хотя у него есть возможность выполнения "по требованию" некоторых транзакций в стиле блокировочника (в таких случаях, как в приведенном мной примере). InterBase - чистый версионник.

kdvвозникает вопрос. если существует взаимосвязь столбцов, то почему для контроля целостности выбран триггер, а не check constraint на таблицу? По-моему дальше можно не продолжать рассматривать этот "пример".Этот "пример" выбран для простоты иллюстрации. Естественно, в данном конкретном случае можно использовать Check conctraint, то есть ситуации, в которых используются именно триггеры или хранимые процедуры (случается же такое иногда? :) ). Городить пример, в котором выкрутиться на Check невозможно, я не стал, полагая, что об этом и так все знают.

Кидман...уверен, что вторая транзакция обламается или сразу, или после коммита первой...Как Вы себе представляете подобный "облом"? Мы говорим "commit", а получаем молчаливый "rollback"? Если возникает ошибка, то какая именно? "Одновременный доступ к данным запрещен настройками"? Или просто "internal error" с выпадением в осадок? :) Если ошибку можно обработать, то что должно стоять в конце обработчика, что-то вроде "commit commit" или "rollback commit"? :) Я готов допустить, что я чего-то недопонимаю или не знаю. Но я привожу примеры, иллюстрирующие свое понимание, либо даю ссылку на первоисточник. Из Вашего, Кидман, поста в стиле "Борист, ты не прав!", мне не удалось понять, в чем конкретно я не прав и почему. Либо проиллюстрируйте (опишите поведение приведенных в примере транзакций на версионнике), либо приведите ссылку на материал, из которого этого стало бы ясно.

GaryaТакая ситуация не может произойти на блокировочнике.Поясню. Если "грязное чтение" разрешено, то либо Транзакция №1 узнает о том, что A стало равно B, либо Транзакция №2. И откатит транзакцию, запретив изменение своих данных. Так что "грязное чтение" может быть не только вредным, но и полезным... :) (перефразированная шутка Фоменко).
Если "грязное чтение" запрещено, то одна транзакция окажется в ожидании завершения другой транзакции. Здесь может подстерегать совсем другая опасность - дедлок (когда Транзакция №1 и Транзакция №2 одновременно ожидают завершения друг друга). Но на блокировочнике действительно ситуация, когда A станет равно B помимо желания разработчиков, воспроизвестись в принципе не может. Кто не согласен - прошу проиллюстрировать на конкретном примере.