Отказ от ответственности: я прочитал все, что мог прочитать по теме моментальных снимков и управления версиями как о переполнении стека, так и в Интернете. Моим требованием является не отслеживание версий для контрольного журнала или моментальных снимков на уровне базы данных. Я потратил более 1 недели на самостоятельное исследование и обдумывание возможных вариантов. Извините, я мог пропустить некоторые ссылки - если решение моей проблемы уже обсуждалось в какой-то другой теме, пожалуйста, ткните меня туда.
Это немного долго; пожалуйста, потерпите меня.
Вот ситуация: мы пытаемся создать общий дизайн для хранения моментальных снимков транзакционных данных в нашей транзакционной базе данных, а также для ведения истории изменений справочных данных.
В рамках бизнес-процесса пользователь может нажать кнопку, чтобы опубликовать определенный объект. Для иллюстрации предположим, что пользователь может опубликовать предложение поставщика до начала переговоров. Затем в разные моменты времени в процессе переговоров пользователь может опубликовать данные предложения. Предложение содержит бюджет, цели продаж и многие другие пункты. При создании моментального снимка предложения необходимо сделать снимок всех связанных объектов. Наконец, после переговоров подписывается контракт. На этом этапе необходимо создать полный снимок контракта. Не все объекты контракта присутствуют в предложении — есть много дублирующих друг друга объектов, но есть уникальные объекты, прикрепленные к предложению и контракту.
Мы должны поддерживать доступ как к этим опубликованным версиям, так и к последним активным версиям. Опубликованные версии доступны на веб-сайте, на который могут ссылаться как поставщики, так и команда менеджеров. Не все опубликованные версии доступны на веб-сайте, но последнее опубликованное предложение и последний опубликованный контракт всегда доступны на веб-сайте. Этот веб-сайт также должен быть заполнен из той же базы данных.
Кроме того, финансовый пользователь может решить сделать снимок только бюджета, а менеджер по продажам может сделать снимок целей продаж. Таким образом, моментальные снимки доступны с разной степенью детализации.
У нас также есть требование отслеживать версии основных данных. Отслеживание всех изменений в ключевых столбцах основных данных с течением времени является бизнес-требованием. Например, у нас есть информация о регионе, связанная с планами продаж. Название региона может измениться, и мы хотим отслеживать эти изменения. Предположим, что на момент предложения имя региона — R1 и создан снимок. Затем имя региона меняется на R2 и создаются 2 других снимка. Мы хотим иметь возможность связать цели продаж с правильным названием региона в эти моменты времени, а не обязательно с последним названием региона.
У нас есть некоторая гибкость в моделировании, поскольку у нас есть как БД транзакций, так и БД хранилища данных, и мы можем решить хранить часть этой информации либо в БД транзакций, либо в БД хранилища данных.
Вот наш дизайн. У нас есть таблица «Публикация», в которой содержится основная информация об опубликованных данных: кто опубликовал, дата, причина и тип опубликованного объекта (предложение, бюджет или цели продаж).
Мы храним снимки в той же таблице, что и исходные данные. Таким образом, снимки предложений будут храниться вместе с текущими предложениями в таблице предложений. У нас есть столбец с именем Publication ID в каждой таблице, которая должна быть опубликована. Этот столбец является FK для таблицы Publication. Если идентификатор публикации равен нулю, эта запись является активной версией.
Я понял, что пост очень длинный. Следовательно, вместо того, чтобы перечислять детали сценария, я решил быстро обобщить соображения дизайна в интеллект-карте. 
Теперь есть 2 решения, к которым мы склоняемся: оба сохранят моментальный снимок всех данных независимо от того, изменились они или нет. Сохранение только дельты при сохранении неповрежденной структуры таблиц потребовало бы очень сложной хранимой процедуры, которая должна запускаться при каждой вставке/обновлении любого объекта моментального снимка. Я не хочу идти по этому пути, так как это займет больше времени, а объемы все равно не такие уж большие.
Решение 1. Каждый раз, когда публикуется объект (например, предложение или бюджет), мы заполняем XML-дерево и сохраняем его в базе данных. На веб-сайте должна быть доступна только последняя версия, а старые версии нужны редко. Учитывая это, могу ли я столкнуться с большой проблемой производительности из-за использования XML? Мы используем SQL Server. Объемы данных невелики.
Решение 2. Все таблицы транзакций будут иметь идентификатор публикации, а справочные данные — даты начала и окончания. Всякий раз, когда объект публикуется, мы делаем копию всех записей транзакций и помещаем туда идентификатор публикации, а также копируем все записи эталонных данных и ставим дату снимка в качестве конечной даты. Это позволило бы нам иметь нормальное управление версиями для справочных данных вне процесса публикации.
Мне нужны мнения опытных умов относительно недостатков этих двух подходов и есть ли какой-либо другой лучший сценарий.
