Как управлять несколькими версиями одной и той же записи

Question

Я выполняю краткосрочную контрактную работу для компании, которая пытается внедрить рабочий процесс типа «регистрация / возврат» для своих записей в базе данных.

Вот как это должно работать ...

1. Пользователь создает новую сущность в приложении. Существует около 20 связанных таблиц, которые будут заполнены в дополнение к основной таблице сущностей.
2. После создания объекта пользователь помечает его как мастер.
3. Другой пользователь может вносить изменения в мастер только «проверяя» сущность. Несколько пользователей могут одновременно оформить заявку.
4. После того, как пользователь внес все необходимые изменения в объект, он переводит его в состояние «требуется утверждение».
5. После того, как авторизованный пользователь просмотрит объект, он может повысить его до мастер-уровня, который переведет исходную запись в захороненный статус.

Способ, которым они в настоящее время выполняют «извлечение», заключается в дублировании записей сущностей во всех таблицах. Первичные ключи включают EntityID + EntityDate, поэтому они дублируют записи объекта во всех связанных таблицах с тем же EntityID и обновленным EntityDate и придают ему статус «извлечено». Когда запись переводится в следующее состояние (требуется утверждение), дублирование происходит снова. В конечном итоге он будет повышен до мастер-класса, и в этот момент окончательная запись будет помечена как мастер, а исходный мастер помечен как мертвый.

Этот дизайн мне кажется отвратительным, но я понимаю, почему они это сделали. Когда кто-то ищет сущность из приложения, он должен видеть все текущие версии этой сущности. Это был очень простой способ сделать это. Но тот факт, что они представляют одну и ту же сущность несколько раз в одной и той же таблице (таблицах), меня не устраивает, равно как и тот факт, что они дублируют КАЖДЫЙ фрагмент данных, а не только хранят дельты.

Мне было бы интересно услышать вашу реакцию на дизайн, будь то положительный или отрицательный.

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

Спасибо!
Darvis

Answer 1

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

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

Единственное, что могло ухудшить ситуацию, - это хранить дельты вместо полных версионных объектов. Итак, смысл этого ответа - не пытайтесь реализовать дельты!

Answer 2

Это похоже на пример временной схемы базы данных. Часто в подобных случаях проводится различие между ключом объекта (в вашем случае EntityID) и первичным ключом строки в базе данных (в вашем случае , {EntityID, date}, но часто это просто целое число). Вы должны признать, что одна и та же сущность представлена ​​в базе данных несколько раз в разные моменты ее истории. Каждая строка базы данных по-прежнему имеет уникальный идентификатор; просто ваша база данных отслеживает версии, а не сущности.

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

Вы можете прочитать об обосновании и дизайне временных баз данных в Википедии

Answer 3

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