Концепция «контроля версий» для строк таблицы базы данных (не относится к хранению скриптов в GIT / SVN) - PullRequest
0 голосов
/ 08 марта 2019

Мне требуется хранилище данных, которое будет хранить не только историю изменений, внесенных в данные (легко сделать), но и хранить любое количество предложенных изменений данных, включая связанные предложения (т. Е. Предложение по предложению).

Думайте об этих «изменениях» как о действительно длительных транзакциях, которые сохраняются в базе данных и имеют срок службы от нескольких минут до нескольких лет.

Они создаются (предлагаются), а затем либо свертываютсяназад (по существу, удалено) или зафиксировано, когда зафиксировано, они становятся эффективными данными, видимыми третьим сторонам.

Конечно, все это требует некоторой формы разрешения конфликта, поскольку предлагаемые изменения могут находиться в противоречивых состояниях (например, изменение A предлагаетудалить запись, но изменение B предлагает обновить ее - если изменение A будет зафиксировано первым, то изменение B придется вернуть)

Я не нашел готового продукта, который мог бы это сделать.Ближайшим был Oracle Workspace Manager, но он не предусматривал изменения при изменении или возможности просмотра предложенных удалений.Единственный способ добиться этого - это иметь набор общих столбцов в моих версионных таблицах:

Root ID : Обязательно - установите один раз на то же значение, что и первичный ключкогда первая версия записи создана.Это представляет первичный ключ за все время и копируется в каждую версию записи.Вы должны учитывать Root ID при именовании столбцов отношения (например, PARENT_ROOT_ID вместо PARENT_ID).Поскольку Root ID также является первичным ключом исходной версии, внешние ключи могут быть созданы для фактического первичного ключа - фактическая желаемая строка будет определяться фильтрами версий, определенными ниже.

Change ID: Обязательно - каждая запись создается, обновляется, удаляется с помощью изменения

Скопировано с идентификатора : Nullable - null указывает на вновь созданную запись, not-null указывает, на какой идентификатор записи эта строкабыл клонирован / разветвлен с момента обновления / удаления

Действует с даты / времени : Nullable - null указывает предложенную запись, not-null указывает, когда запись стала текущей.К сожалению, уникальный индекс не может быть помещен в Root ID / Effective From, поскольку для любого Root ID может быть несколько нулевых значений.(Если вы не хотите ограничивать себя одним предложенным изменением для каждой записи)

Дата вступления в силу / Время : Nullable - null указывает текущее или предлагаемое, not-null указывает, когда оно стало историческим.Технически не требуется, но помогает ускорить запросы для поиска текущих данных.Это поле может быть повреждено вручную, но в этом случае его можно восстановить из даты и времени вступления в силу.

Удалить флаг : Boolean - установить в значение true, если предлагается, чтобызапись будет удалена, когда станет текущей.Когда удаления фиксируются, для их параметра «Дата вступления в силу / время» устанавливается то же значение, что и для параметра «Дата и время вступления в силу», что позволяет отфильтровать их по текущему набору данных.

Запрос для получения текущего состояния данных вмомент времени будет:

SELECT * FROM table WHERE EFFECTIVE_FROM <= :Now AND (EFFECTIVE_TO IS NULL OR EFFECTIVE_TO > :Now)

Запрос на получение текущего состояния данных в соответствии с изменением будет:

SELECT * FROM table WHERE (CHANGE_ID IN :ChangeIds OR (EFFECTIVE_FROM <= :Now AND (EFFECTIVE_TO IS NULL OR EFFECTIVE_TO > :Now) AND ROOT_ID NOT IN (SELECT ROOT_ID FROM table WHERE CHANGE_ID IN :ChangeIds)))

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

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

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

...