Хранение изменений в записях

Question

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

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

1. Одно таблица/одно поле - в основном есть одна таблица, в которой хранится история всей таблицы, которая требует хранения истории. Все изменения записываются в одном поле в виде типа текстовых данных.
2. Таблица на таблицу/одно поле - то же самое, что и выше, за исключением того, что каждая таблица имеет свою собственную таблицу истории (т.е. проекты/проект, выпуски/эмиссия и т. Д.).
3. Таблица на таблицу/поле для поля - это похоже на вышеупомянутое в каждой таблице имеет свою собственную таблицу Histroy, но также таблица истории имеет почти то же определение, что и обычная таблица, с дополнительными дополнительными полями, связанными с историей (UpdateTeTime, UpdateUserid, так далее...).

Каковы некоторые из преимуществ и недостатков для этих различных методов хранения истории записей? Есть ли другие методы, о которых я не думал?

Answer 1

Поскольку у вас есть много таблиц с различным количеством столбцов, #1 вышел бы, так как у вас будет огромная таблица со совокупностью всех ваших столбцов и множеством нулевых.

Между #2 и #3 я думаю, что у вас есть решение принять в отношении сложности дизайна, с которой вы хотите управлять. Я считаю, что было бы легче поддерживать точную архивную копию для данной таблицы и сохранить всю ленту (с измененным временем). Подумайте о случае, когда вы обновляете более одного столбца строки. В этом случае № 2 зарегистрировал бы запись для изменения столбцов отдельно, хотя это была та же транзакция. Я бы пошел в W #3 для уменьшения сложности и захвата состояния временного ряда.

Answer 2

Вы действительно хотите прочитать в первую очередь:

http://www.cs.arizona.edu/~rts/tdbbook.pdf

Если вы хотите сохранить свою историю в отдельной таблице (и, вероятно, вы это делаете), вы, вероятно, захотите вариант № 3; Это, как правило, легче реализовать и более удобно, #1-2 довольно уродливые и «нереляционные».

Answer 3

В некоторой степени это зависит от того, как вы намерены использовать эти данные. Если это таблица аудита, используемая строго, чтобы иногда исследовать, кто изменил то, что и когда и иногда восстанавливает плохие изменения, то вариант 2 в порядке. Если вы намереваетесь отобразить историю пользователя в приложении или через отчеты, используйте опцию 3. Я не могу придумать обстоятельств, когда я бы использовал вариант One, так как оно считает места, где происходит блокировка.