Предложения по дизайну, необходимые для журнала или истории транзакций

Question

Я разрабатываю веб-приложение, в котором пользователи, принадлежащие к разным группам, будут заполнять форму и представлять ее. Сценарий: Пользователь A, B и C принадлежат группе G. Пользователь A записывает в приложение, заполняет форму (например, возраст = 30), отправляет то же и выйдет из системы. Теперь пользователь B регистрируется в приложении, открывает ту же форму (например, возраст = 35), редактирует форму и сохраняет ее. Теперь пользователь C делает то же самое (например, возраст = 40). Когда другой пользователь откроет форму, он покажет возраст как 40 (так как это последняя запись).

Вопрос: если администратор входит в приложение, он должен иметь возможность видеть всю историю транзакций или журналов. Пожалуйста, предложите мне некоторый подход к дизайну, когда все изменения регистрируются в базе данных. Есть ли какие-либо рамки, такие как весна или спящий режим или любая помощь для достижения этого? Любые входы в дизайн базы данных также помогут мне.

Я использую Struts и простой JDBC с SQL Server.

Answer 1

К нему можно подойти несколькими способами.

1. Log4j Регистрация. Согласитесь с шаблоном и зарегистрируйте обновления в файле журнала. У вас есть инструменты, такие как сумологический или splunk или Kibana, который может индексировать файлы журнала. Однако эти решения не могут вести журнал навсегда. Как правило, вы можете проектировать их для хранения данных за 3 месяца. Вы можете запросить ключевые слова, и вы получите результаты за миллисекунды!
   2. Если вы используете спящий режим, у вас есть что-то, называемое envers. Какая запись последней строки db в таблицу аудита перед ее модификацией. Но ограничение в том, что вам нужно находиться в спящем режиме
   3. Используйте триггеры db. В триггере обновления (atleast mysql) вы получаете измененные столбцы, и вы можете их записать. Единственной проблемой является захват пользователя, который выполнил операцию, которая может быть отправлена ​​в mysql-соединение как «временная переменная». Однако администраторы баз данных кричат, когда и рассказывают о триггерах (почему? I ddont знают!)