Как реализовать историческое управление версиями?

Question

Мы находимся на ранних стадиях создания большого приложения C # MVC2 (мы также используем архитектуру Sharp и Nhibernate как часть экосистемы) в SQL 2008 R2, и одно из требований состоит в том, что все версии строк базы данных доступны дляданный период истории.

Мы играли с идеей макета, подобного:

id (PK)
recordId
versionId

и каждыйредактировать в результате записи в новой записи, созданной с тем же recordId и увеличенным versionId.Отображение записи будет затем выполнено с помощью чего-то вроде SELECT ... WHERE recordId = X AND versionId = MAX (versionId)

Снимок на каждой транзакции не будет работать (слишком много? И не будет доступен изприложение легко).

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

Answer 1

Вы, кажется, намекаете на временную таблицу. Три подхода:

Таблица действительных состояний : добавление двух столбцов 'timestamp' (например, типа DATETIME), один из которых указывает, когда строка стала действительной, а другой - когда строка перестала быть действительной, промежуточное время равно срок действия строки

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

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

Источник: Разработка ориентированных на время приложений баз данных на SQL (Ричард Т Снодграсс) .

Answer 2

У нас есть система, разработанная нашими администраторами баз данных, которая работает как триггер при обновлении / удалении.Существует вторичная таблица, которая почти отражает ревизуемую таблицу (кроме некоторых других деталей, таких как время транзакции, имя входа, использованное для обновления, сервер и т. Д.).Каждый раз, когда кто-то вносит изменения, он регистрируется в версии аудита таблицы через триггер.Отчасти раздражает необходимость поддерживать триггер аудита в актуальном состоянии в любое время, когда меняется схема, но c'est la vie.

Хорошая вещь в этом заключается в том, что приложениям не нужно заниматься этим аудитом вообще ... таким образом, он сохраняет подсчет концепции для кода приложения низким (er).

Он находится в производстве и работает с таблицами, где число транзакций исчисляется десятками тысяч в день.Ваш пробег может, конечно, варьироваться в зависимости от ряда факторов, таких как размер вашего сервера и характер ваших данных, но это работает для нас: -)

Answer 3

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

Самая большая проблема, с которой мы столкнулись, была производительность при попытке использовать только функции NHibernate для управления массовыми вставками и обновлениями (потому чтоинтерфейс потребовал их).Поэтому мы решили использовать TRIGGERS для проверки всей информации в таблицах, и время отклика невероятно, сравнивая любое решение, которое мы могли бы предложить в этот раз с NH.

Если кто-то спросит меня, как это сделать, ясказал бы, триггеры - это способ проверки ваших данных.

Answer 4

Вместо versionId, который требует от вас самостоятельного объединения для получения максимальной версии, я бы представил пару validFrom - validTo.Это требует обновления (окончания) текущей записи validTo при вставке новой версии строки, но позволяет легко выбирать текущие данные с помощью where @now >= validFrom and @now < validTo или данных в любое историческое время.

Вы можете иметь эти исторические записив отдельной таблице или нет.Если вы хотите иметь только одну таблицу, включающую все версии строк, которая лучше обслуживается и может использоваться, вы можете взглянуть на разделы SQL Server (многораздельные таблицы), которые позволяют отделить недавнюю историю от старой истории и оптимизировать поискна нем.

Answer 5

Если у вас SQL 2008 Enterprise, и, в зависимости от ваших намерений, может понадобиться посмотреть Change Data Capture (CDC).

Это действительно зависит от того, сохраняете ли вы предыдущие версии для целей аудита или для некоторыхдругая причина.

Answer 6

Мое предприятие также использует подход на основе триггеров как для аудита, так и для истории. В дополнение к основной таблице на корпоративном складе каждая значимая таблица имеет таблицу аудита в отдельной базе данных. Эта таблица аудита имеет 1 строку для каждой транзакции. Некоторые из наших таблиц также имеют историческую версию в третьей базе данных. База данных Audit предназначена исключительно для устранения неполадок и устранения сомнений, но запрос на анализ данных затруднителен и неэффективен. Наша база данных истории оптимизирована для очень эффективного ответа на запросы времени. Все это на 100% написано с помощью написанного мной инструмента .net, поэтому, когда мы изменяем схему или добавляем новые таблицы в историю, мы просто перепрограммируем соответствующие триггеры.