История изменений данных с помощью таблиц аудита: группировка изменений

Допустим, я хочу хранить пользователей и группы в базе данных MySQL. Они имеют отношение n: m. Для отслеживания всех изменений каждая таблица имеет таблицу аудита user_journal, group_journal и user_group_journal. Триггеры MySQL копируют текущую запись в таблицу журнала для каждого INSERT или UPDATE (DELETES не поддерживаются, потому что мне нужна информация, какой пользователь приложения удалил запись - поэтому есть флагactive это будет установлено в0 вместо удаления).

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

Лучшим решением было бы объединить все изменения, сделанные в рамках транзакции. Поэтому, когда пользователь обновляет имя группы и добавляет 10 пользователей за один шаг (один вызов контроллера формы), это будет один шаг в истории. Может быть, можно определить случайный хеш или увеличить глобальный счетчик каждый раз, когда транзакция запускается, и получить доступ к этому значению в триггере?

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

Ответы на вопрос(2)

Ваш ответ на вопрос