Как отслеживать изменения в булевом столбце в базе данных MySQL?

Question

Мое приложение обслуживает клиентов, которые являются интернет-магазинами. Одна из таблиц в моей БД - «Продукт», и у нее есть столбец «In_Stock». Это булевский (бит (1)) столбец. Мои клиенты отправляют каналы данных своего каталога продуктов, и каждый клиент имеет собственную версию этой таблицы. Я хотел бы, чтобы отслеживать изменения в этом столбце На складе, то к эффекту ...

11/13/2016 true 
12/26/2016 false 
01/07/2017 true 

Просто так, что когда я делаю какой-то аудит, я могу видеть в течение определенного периода времени, что было состояние данный продукт.

Как лучше всего это сделать?

Кажется излишним создать отдельную таблицу истории и обновить ее с помощью триггера только для одного булевского столбца. Столбец истории достаточно? Я могу сохранить данные там в какой-то строке JSON.

Answer 1

я сделал триггер предмет. Но не реплицируйте весь столбец - возьмите уникальный идентификатор столбца, log timestamp и boolean значение. Иногда хорошие журналы являются бесценными :)

Answer 2

Извините, для любого работоспособного решения потребуется вторая таблица.

Одним из таких решений является версия нормальной формы (vnf), которая является частным случаем 2nf. Рассмотрим таблицу, содержащую логическое поле (при условии, что она нормализована как минимум на 3nf). Теперь вы хотите отслеживать изменения, сделанные в логическом поле. Один из способов - превратить строки в версии, добавив столбец EffectiveDate, вместо этого, вместо обновления строки, напишите новую строку с текущей датой в поле даты (или обновив, если логическое поле не изменилось).

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

Но внимательно посмотрите на дизайн. Перед изменением у вас была хорошая нормализованная таблица без отслеживания изменений. После добавления колонки EffectiveDate произошли незначительные изменения. Все поля, кроме булевского поля, по-прежнему зависят только от ПК. Логическое поле зависит не только от PK, но и от нового поля даты. Это больше не 2nf.

Нормализация таблицу требует перемещения булево поле и поле даты в новую таблицу:

create table NewTable(
    EntityID int not null references OriginalTable(ID), 
    EffDate date not null, 
    TrackedCol boolean, 
    constraint PK_NewTable primary key(EntityID, EffDate) 
); 

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

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

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

Answer 3

Для этой цели я написал audit trail module, он в основном дублирует таблицу, добавляет некоторую информацию в каждую строку и сохраняет исходную таблицу данных без изменений, за исключением триггеров.