Разработка снимков в транзакционной базе данных с указанием версий справочных данных

Question

Отказ от ответственности: я прочитал все, что я могу прочитать на тему снимков и версий как при переполнении стека, так и в Интернете. Мое требование - не отслеживание версий для контрольного журнала или снимков уровня базы данных. Я потратил больше 1 недели, чтобы самостоятельно изучить и обдумать возможные варианты. Извините, я мог пропустить некоторые ссылки - если решение моей проблемы уже обсуждалось в какой-то другой ветке, пожалуйста, укажите меня там.

Это немного долго; пожалуйста, потерпите меня

Вот ситуация: мы пытаемся создать общий дизайн для хранения моментальных снимков транзакционных данных в нашей транзакционной базе данных, а также для сохранения истории изменений справочных данных.

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

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

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

У нас также есть требование отслеживать версии основных данных. Это бизнес-требование, чтобы отслеживать все изменения в ключевых столбцах основных данных с течением времени. Например, у нас есть информация о регионе, связанная с целями продаж. Название региона может измениться, и мы хотим отслеживать эти изменения. Предположим, что на момент подачи заявки регион называется R1, и создается снимок. Затем имя региона меняется на R2, а затем создаются 2 других снимка. Мы хотим иметь возможность связать цели продаж с правильным названием региона в те моменты времени, а не обязательно с последним названием региона.

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

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

Мы сохраняем снимки в той же таблице, что и исходные данные. Таким образом, снимки предложений будут храниться с живыми предложениями в таблице предложений. У нас в каждой таблице есть столбец «Идентификатор публикации», который необходимо опубликовать. Этот столбец является FK таблицы публикации. Если идентификатор публикации равен нулю, эта запись является активной версией.

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

Теперь есть 2 решения, к которым мы стремимся - оба хранят снимок всех данных, независимо от того, изменились они или нет. Поддержание только дельты при сохранении неизменности структур таблиц потребует очень сложной хранимой процедуры, которая должна выполняться при каждой вставке / обновлении любого объекта моментального снимка. Я не хочу идти по этому пути, так как это заняло бы больше времени, и объемы в любом случае не такие большие.

Решение 1. Каждый раз, когда объект публикуется (например, предложение или бюджет), мы заполняем дерево XML и сохраняем его в базе данных. На сайте должна быть доступна только последняя версия, а старые версии нужны редко. Учитывая это, я столкнулся бы с большой проблемой производительности из-за использования XML? Мы используем SQL Server. Объемы данных невелики.

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

Мне бы понадобились мнения опытных умов о недостатках этих двух подходов и о том, есть ли какой-нибудь другой лучший сценарий.

Answer 1

Мой подход заключается в выборе решения 2. Принимая ваши конструктивные соображения в следующем порядке:

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

2. Я бы выбрал вариант, не упомянутый на вашей диаграмме, хотя он и очерчен в вашем описании решения 2. При этом используется схема, очень похожая на схемуБД транзакций, но расширенная для включения информации, относящейся к снимкам.Вы упоминаете идентификатор публикации в качестве внешнего ключа и даты для справочных данных.Возможно, вам понадобится дополнительная информация, например даты, связанные с данными транзакции.

3. Та же схема не подходит - вы указали (идентификатор публикации), что эта схема не являетсяадекватны.Ничто из того, что вы публикуете, не говорит о том, что вам нужно принять другую схему, оптимизированную для чтения.Даже если это окажется необходимым, это то, что может быть включено на более позднем этапе, с текущей расширенной схемой в качестве отправной точки.У меня нет большого опыта работы с деревьями XML, но я бы спросил: «Зачем внедрять другую технологию, если у вас есть альтернативы, которые могут использовать вашу существующую инфраструктуру?»Любое преимущество, которое вы почувствуете при таком подходе, должно быть очень значительным, чтобы исключить преимущество использования вашей существующей архитектуры.Аналогичные соображения применимы к денормализованной БД.Зачем идти туда, пока в этом нет явной необходимости?

4. Снова я бы принял подход к отслеживанию версий и снимков.Вы получаете основное преимущество этого подхода в своем решении 2. Я бы добавил моментальные снимки справочных данных как часть процесса создания снимков, а не как процесс создания версий.(Т. Е. Когда снимок сделан, убедитесь, что соответствующие справочные таблицы являются частью снимка).Из вашего описания видно, что у вас есть два разных требования, которые могут использовать одни и те же данные - моментальный снимок и управление версиями.Кажется, между ними мало зависимости, поэтому вы должны сохранять их как можно более независимыми - отсутствие связи.

5. Вы упоминаете о возможном использовании хранилища данных в качестве хранилища, хотя это и не упоминается в ваших решениях.Если ваши объемы, как вы предлагаете, низкие, то я бы подумал, что отдельная база данных была адекватной.У вас создается впечатление, что объемы как данных, так и пользователей для моментальных снимков невелики, так что, похоже, не было бы достаточных оснований для использования хранилища данных.В то же время в хранилище есть некоторые механизмы для хранения именно этого типа исторических данных, которые будут использоваться для чтения и анализа.

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