Dmitry Voroninпри закрытии периода, архивации и т.п. можно удалять все версии документа из БД, оставляя только основную
Если есть изменения и расчеты задними числами, то не сработает. Например задним числом поменялась ставка аж за полгода назад. Необходимо пересчитать все договора за эти полгода. Если у Вас по изменению всех аттрибутов договоров, участвующих в расчете история не ведется или очищается при закрытии расчетного периода, то расчет будет произведен по значениям, действующим на текущий момент времени и соответствующе выдаст не правильные результаты при пересчитывании прошлых периодов. Это хорошо, когда весь расчет = ставка*значение, а вот чего нибудь посложнее: расчет зп, расчет коммунальных плателей, расчет потребления электроэнергии пром. абонентами и т.д., это целая песня, где фактически на все приходиться вести хранение истории. У меня например в расчете зп ЕСН вообще по двум измерениям ведется: для авансовых платежей в течении года он расчитывается по месяцу начисления (т.е. берется со всех сумм начислений, вошедших в расчетный месяц, в том числе и результатов сторнирования прошлых закрытых периодов), а в конце года он формируется по месяцу выдачи (т.е. пересчитывается так, как если бы в расчетном году изменений задними числами не было и начисления велись без сторно, по месяцам).

Так что если у Вас таких расчетов нет (и слава богу), то лучше просто перебрасывать историю в отдельные таблицы и так не заморачиваться. Если что то такое есть, то лучше подумать о варианте номер 1, предложенным UK0IAI .

авторА на мой взгляд это разные вещи. История изменения цен должна храниться полностью.
А какой смысл хранить историю полностью ? Я в своей модели хранения истории могу гарантировать, что за любой расчетый период я могу получить входящую информацию, соотвествующую тому расчетному периоду и которая будет основой для расчетной информации. Что там юзер менял в течении месяца меня не волнует, самое главное, что было использовано при расчетах. Это и есть состояние истории де-факто, которое фиксируется при закрытии расчетного месяца и в будующем больше изменится не может. Другое дело, что юзер может провести изменения задним числом, однако это опять же будет на самом деле не изменение значения входящей информации за прошлый расчетный период, а добавление в историю новой версии по закрытой информации. Ну а если юзер ошибочно ввел что то, потом рассчитал и закрыл расчетный месяц, так это извините его проблемы чисто в бухгалтерском понятии. Будет в следующем месяце менять эту информацию задним числом, чтобы программа автоматом сторнировала ему эту разницу ошибки.

авторНу а на практике, все это можно комбинировать. Отдельным вопросом стоит "будущая история". Напр. изменили мы некий атрибут 25-м апреля (будущего), а затем заново изменили 14 апреля, а потом удалили его вообще 19-го... Тут такой простор мыслей открывается....
У меня с будующим все просто. Так как есть 2 даты на информацию - дата нач.действия (SaveDate) и дата расчетного месяца (CalcDate), то хранится следующим образом:
допустим текущий расчетный месяц @@CurCalcDate = Апрель 2004

добавляем информация за тек. расч. месяц:
CalcDate=2004.04.01
SaveDate=2004.04.01

изменяем информацию задним числом за март 2004:
CalcDate=2004.03.01
SaveDate=2004.04.01

добавляем информацию будующим числом на май 2004:
CalcDate-2004.05.01
SaveDate=2004.05.01

Получается, что SaveDate при записи в БД вычисляется по следующей формуле:
CASE WHEN SaveDate <= @@CurCalcDate THEN @@CurCalcDate ELSE CalcDate END

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

авторА если расчетный период тот же, а цены менялись несколько раз и изменяется запись с предыдущими ценами, тут хочешь не хочешь, а хранить историю будешь. Плюс к этому по истории изменения цен можно получить динамику изменения.
Давайте определимся с терминологией, иначе сейчас запутаемся :) Говоря история я имею ввиду историю изменения (в том числе и задним числом) аттрибутов обьекта, которые являются статическим зафиксированным значением в неком периоде и уже не могут изменяться (версии значений). Сама длина этого периода определяется конкретной задачей. Например, если цена продукции изменяется раз в месяц, то сколько бы ее юзера не меняли в течении месяца, в конце концов в истории будет одна цена, вернее ее последняя версия. Если цена продукции может изменятся каждый день, то значит мы будем хранить ее историю за каждый день изменений. Опять же в зависимости от ТЗ мы будем определять, когда юзеру доступно изменение информации, а когда он уже должен добавить ее новую версию. Например, в расчете зп есть понятие расчетного периода размером в месяц. Однако ставки могут изменяться хоть каждый день. Получается что юзер имеет право изменять значение ставки хоть на каждый день месяца. Сколько дней он распишет, столько записей по этой ставке и будет. Однако, если он захочет задним числом изменить ставку с 15 числа прошлого закрытого месяца, то в интерфейсе именно так он и сделает. Однако на самом деле в БД будет добавлена новая версия по этой ставке, с указанием что с 15 числа прошлого месяца значение ставки теперь такое, однако запись будет помечена, что проведена она текущим месяцем. Это я и называю историей (версионностью значений данных) - каждые аттрибуты обьекта, взятые во времени всегда являются дефакто и не противоречат остальным данным системы за период их действия. То есть, если я запущу расчет зп за прошлый месяц с точки зрения данных прошлого месяца, то мне и будет все посчитано так, как было в прошлом месяце, цифра в цифру. Если же расчет будет запущен с точки зрения данных текущего месяца, то у меня получатся другие результаты. Разница между результатами и есть сторно, причем опять же в архиве закрытых периодов за прошлый период расчетные данные изменяться не будут, разница сторно пойдет в текущий месяц, с пометкой, что она содержит данные за прошлый расчетный месяц.

В случае же выяснения обстоятельств неправильного ввода информации я это называю логированием данных (протоколом). Это совсем другая песня из другой оперы - такие вещи я выношу отдельно.

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

Сорри, если написал сумбурно, очень сложно описывать проблемы и решения, связанные с проектировкой БД, до сих пор у меня криво получается, никак не научусь :)