Как создать версию динамических бизнес-объектов / данных?

Question

Мы разрабатываем большие приложения, которые связаны с бизнесом. Вы можете найти эти приложения похожи на некоторые ERP, CRM и т. Д.

Теперь у нас есть требование, чтобы все данные, которые вводит пользователь, были версионированы.

Например: в какой-то момент пользователю потребуется просмотреть историю изменений конкретного заказа на покупку?

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

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

Есть идеи или мнения?

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

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

Answer 1

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

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

Например, пусть у вас есть экземпляр Order, который содержит список OrderItem с, и вам нужно добавить определенный OrderItem в этот список. В этом случае вы создаете новый экземпляр Order на , заменяя его список элементов новым списком, который, в свою очередь, создается cons ' добавление нового OrderItem в старый список.

Позвольте мне проиллюстрировать этот пример далее в картинках. Представьте себе хранилище объектов (пусть это будет ОЗУ или реляционная база данных, что угодно):

Address | Object             | Created by
--------+--------------------+------------------------------------------
   1000 | list of OrderItems | empty list constructor
   1001 | Order              | Order constructor, uses address 1000
                  ...         
   1300 | OrderItem          | ...
   1501 | list of OrderItems | cons of addr 1300 to addr 1000
   1502 | Order              | replace order_items in addr 1001 by addr 1501

Сама структура хранения данных таким образом постоянна (Крис Окасаки подробно описывает это в своей диссертации , например). Вы можете восстановить любую версию объекта, просто следуя его истории создания; управление версиями становится тривиальным. Просто запомните главное: не изменяйте данные, вместо этого создавайте новые экземпляры.

Answer 2

Что-то похожее на Hibernate Envers - решение Entity Auditing, похоже, хорошо соответствует вашим требованиям.

Answer 3

В прошлом мне приходилось делать что-то похожее на это.

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

По сути, индекс становится номером версии рассматриваемого объекта, и любой запрос к БД для последней версии будет использовать квалификатор WHERE NextVersionIndex=0.

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

Answer 4

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

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

Answer 5

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

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