Лучшая практика для реализации режима долгосрочной истории для системы O / RM (Hibernate)?

Я сопоставил несколько классов Java, таких как Customer, Assessment, Rating, ... с базой данных с Hibernate. Теперь я думаю о режиме истории для всех изменений постоянных данных. Приложение представляет собой веб-приложение. В случае удаления (или редактирования) данных другой пользователь должен иметь возможность увидеть изменения и отменить их. Поскольку изменения выходят за рамки текущего сеанса, я не знаю, как решить эту проблему с помощью чего-то вроде шаблона Command, который рекомендуется для функции отмены.

Для редактирования одного значения подход, подобный этому вопросу, звучит нормально. Но как насчет удаления всей постоянной сущности? Самый простой способ - поставить отметку в таблице, если этот покупатель удален или нет. Самый сложный способ - создать таблицу для каждого класса, в которой хранятся удаленные сущности. Есть что-нибудь посередине? И как я могу с комфортом интегрировать эти две вещи в систему O / RM (в моем случае Hibernate), не возясь с SQL (чего я хочу избежать из-за переносимости), и при этом иметь достаточную гибкость?

Есть лучшая практика?


person maerch    schedule 15.10.2008    source источник


Ответы (3)


Один из способов сделать это - иметь сущность «истории изменений» со свойствами для идентификатора сущности измененной сущности, действия (редактировать / удалить), имени свойства, первоначального значения, нового значения. Возможно также ссылка на пользователя, выполняющего редактирование. При удалении будут созданы сущности для всех свойств удаленной сущности с действием «удалить».

Этот объект предоставит достаточно данных для выполнения отмены и просмотра истории изменений.

person Jonas K    schedule 15.10.2008

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

По сравнению с подходом «атрибут за атрибутом» это значительно упрощает откат или просмотр исторических версий, но занимает больше места.

person Bell    schedule 15.10.2008
comment
Ваш подход звучит интересно. У меня к этому два вопроса. 1) Где вы храните этот номер версии? В таблице для самой сущности или в отдельной таблице 2) как избежать конфликтов с неоднозначными первичными ключами для этих различных сущностей, которые всегда должны иметь одни и те же ключи? Спасибо - person maerch; 15.10.2008
comment
Обычно я храню номер версии в самой сущности. Номер версии может быть объединен с полем id для создания уникального первичного ключа. - person Bell; 16.10.2008

Хм, я тоже ищу ответ. Пока что лучшее, что я нашел, - это фреймворк www.jboss.org/envers/, но даже это кажется мне большим объемом работы, чем следовало бы.

person Community    schedule 24.11.2008