Проектирую базу данных для системы, которая будет вести учет оплаты счетов клиентами, наших оплат субподрядчикам и т.п.

Есть две типовые задачи:
1. Вести учет изменений всех документов
2. Иметь возможность "заморозить" данные скажем клиента на тот момент, когда ему был выписан счет.

Для примера самый простой случай - есть два объекта:

Счет клиенту { Какому клиенту, За что выписан счет, Дата выписки, Сумма, флаг "счет закрыт"}

Клиент { Имя, Телефон }

Требуется:
1. Иметь возможность посмотреть всю историю изменений одного счета (скажем, изменение суммы разными пользователями, пока счет не был закрыт)

2. Иметь возможность менять данные клиента (скажем, у него изменился телефон), но закрытые счета всегда должны ссылаться на данные клиента, которые были на момент выписки счета.

Я понимаю, что задача решалась сотни раз и есть типовые решения. Хотелось бы услышать сравнительные за и против разных подходов, которые помогли бы избежать неизбежных граблей при развитии и усложнении задачи (например - появляются ссылки на счет, затем клиент ссылается на что-то еще и т.д.)
Буду очень благодарен за любые ссылки, или просто советы.

От себя могу предложить следующие варианты:

1.1 История изменений хранится в таблице, которая имеет ту же структуру, что и оригинальная, с добавлением полей "дата изменения", "пользователь", "операция: I, U, D", "версия рядка".

или

1.2 История изменений хранится просто как xml-строка

или

1.3 история изменений хранится в виде двух таблиц. В одной храним объект, который менялся, в другой - его поля

Относительно хранения счета в том виде, в каком он был:
2.1 Просто храним xml строку и все дела
2.2 Все закрытые счета копируем в отдельную таблицу, таблица клиентов содержит актуальные на данный момент данные, которые копируются в отдельную таблицу, когда счет закрывается.
2.3 Храним актуальные данные и историю изменений с версией (две разные таблицы). Когда счет выписывается - записываем туда ссылку на таблицу изменений и соотв. версию

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

Заранее благодарен за ответы

вариант, конечно.
Но тогда при выводет текущего состояния объекта скажем Клиент придется каждый раз делать выборку по всей базе и искать последнюю версию.
Хранить ссылки на последнюю версию в отдельной таблице тоже не кажется лучшим решением.

Внимательно прочитал статью, спасибо за ссылку которую я не нашел.

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

У меня же будет ASP.NET 3.5 на C# + LINQ, вопросы быстродействия не столь важны, и пока вообще не до триггеров.

Интересен опыт (статьи) проектирования именно вышеописанных задач, т.е. с упором на бухгалтерию.

Например, я работал с системой Accpac, там, похоже как и во многих других, существует понятие документа, который вроде бы представляет собой что-то типа одной записи в истории изменений (оплата счета), и лишь ссылается на счет и клиента.

Словом, пока информация немного не о том, что хочется