Эффективная стратегия для оставления истории аудита trail/изменений для DB приложений?

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

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

Если вы используете Hibernate, посмотрите на JBoss Envers . С главной страницы проекта:

Проект Envers направлен на упрощение управления версиями постоянных классов JPA. Все, что вам нужно сделать, это аннотировать ваш постоянный класс или некоторые его свойства, которые вы хотите изменить, с помощью @Versioned. для каждой версионной сущности будет создана таблица, которая будет содержать историю изменений, внесенных в сущность. Затем вы можете без особых усилий извлекать и запрашивать исторические данные.

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

В прошлом я использовал триггеры для построения журнала db update/insert/delete.

Вы можете вставлять запись каждый раз, когда одно из вышеперечисленных действий выполняется в определенной таблице, в таблицу ведения журнала, которая отслеживает действие, то, что сделал пользователь БД, timestamp, таблицу, в которой оно было выполнено, и Предыдущее значение.

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

Единственная проблема с использованием триггеров заключается в том, что он добавляет к производительности накладные расходы любого insert/update/delete. Для повышения масштабируемости и производительности необходимо свести транзакцию базы данных к минимуму. Аудит с помощью триггеров увеличивает время, необходимое для выполнения транзакции, и в зависимости от объема может вызвать проблемы с производительностью.

другой способ-изучить, предоставляет ли база данных какой-либо способ извлечения журналов "Redo", как это имеет место в Oracle. Повтор журналов-это то, что база данных использует для воссоздания данных в случае сбоя и необходимости восстановления.

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

Кроме того, можно повысить производительность базы данных-источника, сохранив базу данных аудита в отдельном расположении.

Я использую SQL сервер, а не PostgreSQL, так что я не уверен, будет ли это работать для вас или нет, но у попа Риветта была отличная статья о создании аудита trail здесь: Поп Риветт сервер SQL FAQ No.5: Поп на аудит Trail

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

Подсказка: используйте Codesmith для создания триггеров.