Каков был бы хороший подход к проектированию для отслеживания «истории» записей в триггерах веб-приложения J2EE + MySQL, против хранимых процедур и против логики приложения?

Question

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

Вот некоторые идеи дизайна, которые я имею в виду, но не знаю, какой подход лучше / лучше использовать:

1. Создайте дублирующую схему (или дублирующую таблицу для таблицы) для текущих таблиц.Вызвать триггер перед обновлением для каждого из них.Но я хочу, чтобы он срабатывал только в случае изменения «текста», а не других атрибутов.Даже не знаю, как это сделать
2. Создайте «таблицу истории», т. Е. Глобальную таблицу, в которой атрибут используется для изоляции таблицы / элемента, для которого предназначена запись истории.
3. Имейте асинхронный компонент, который отвечает за обновление специальной таблицы (таблиц) с соответствующим обновлением - больше похоже на тип хранилища hashmap.Но я не знаю, как это можно сделать с помощью Java / Mysql или оно того стоит.Создание асинхронных компонентов нетривиально

В первом из двух подходов использовались бы триггеры.Но тогда я не хочу, чтобы триггер что-либо делал, если только метка времени или другие поля конфигурации были обновлены для записи.Предполагая, что около 50-100 одновременно работающих пользователей, будут ли триггеры хорошим вариантом?(или лучше использовать подход хранимых процедур, чтобы сделать это ... не уверен).

Намерение такого дизайна: мы хотим в основном выполнить некоторый анализ данных об изменениях / удалениях и т. д.,Мы также хотим проверить «добавленные новые элементы», но это легко из временной отметки и не влияет на аспект истории.Мне нужно было по-разному спроектировать каждый из вышеперечисленных пунктов, и я хотел знать, как лучше всего подойти к проблеме, т. Е. Как лучше всего справиться с чем-то подобным в корпоративных приложениях.Я хотел, чтобы сообщество провело его, чтобы получить некоторые предложения / указания / преимущества для некоторых подходов.Новые / другие лучшие подходы приветствуются!

Я просмотрел несколько постов по SO, и они кажутся специфичными для БД, но не обязательно отвечают на мой вопрос напрямую - они говорят мне, как для первого варианта, но не обязательно, является ли это хорошим способомДля этого: Рекомендации по отслеживанию истории данных и Как отслеживать изменения данных в таблице базы данных

PS: я не использую ORM, а скореесобирается с весны JDBC.Было решено, что ORM не стоит того ...

Answer 1

• Записать записи в дублирующуюся схему для таблиц истории, используя java. Поддерживать Java легче, чем поддерживать триггеры.

• При ведении журнала нет необходимости проверять различия.

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

Answer 2

То, что вы, вероятно, спрашиваете, называется контрольным журналом. Наилучшим способом является ведение отдельной таблицы контрольного журнала для ведения действий (добавление / удаление / изменение).

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

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

Механизм очистки очищает (каскадное удаление) мастер и контрольный журнал на основе заранее определенного интервала.

Я использовал комбинацию app-logic и sql запросов. нет сохраненных процедур.