История базы данных для использования клиентом

Question

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

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

Я пытаюсь выяснить, как лучше всего поступить. Любые предложения будут оценены.

Я использую Oracle + VB.NET

Answer 1

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

Answer 2

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

Если вы используете API-интерфейс PL / SQL для выполнения INSERT / UPDATE / DELETE, вы можете управлять этим простым изменением структуры без необходимости (заранее) для таблиц истории.

Все, что вам нужно, это 2 дополнительных столбца, DATE_FROM и DATE_THRU. Когда запись вставлена, DATE_THRU остается NULL. Если эта запись имеет значение UPDATEd или DELETEd, просто «завершите дату» записи, сделав DATE_THRU текущей датой / временем (SYSDATE). Показать историю так же просто, как выбрать из таблицы, единственная запись, в которой DATE_THRU равен NULL, будет вашей текущей или активной записью.

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

Надеюсь, это поможет.

Answer 3

Если вам достаточно повезло с Oracle 11g, вы также можете использовать Flashback Data Archive

Answer 4

У нас есть это требование в наших системах. Мы добавили две таблицы, один заголовок, одну деталь под названием AuditRow и AuditField. AuditRow содержит одну строку на строку, измененную в любой другой таблице, а AuditField содержит одну строку на столбец, измененную со старым значением и новым значением.

У нас есть триггер для каждой таблицы, который записывает строку заголовка (AuditRow) и необходимые строки сведений (по одной на измененный столбец) при каждой вставке / обновлении / удалении. Эта система опирается на тот факт, что у нас есть руководство по каждой таблице, которая может уникальным образом представлять строку. Не обязательно должен быть «рабочий» или «первичный» ключ, но это уникальный идентификатор для этой строки, чтобы мы могли идентифицировать его в таблицах аудита. Работает как чемпион. Overkill? Возможно, но у нас никогда не было проблем с аудиторами. : -)

И да, таблицы аудита являются безусловно самыми большими таблицами в системе.