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

Question

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

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

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

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

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

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

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

Спасибо!
Darvis

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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