Лучшая реализация для полностью auditable модели данных?

You can also create a logging system in application code. Log calls to every function that modifies the database and results in a successful COMMIT.

Answer to your question: no, just use a RDBMS. It'll be easier to run queries on the log.

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

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

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

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

Предостережения:

Create a table that holds the names of the tables you want to audit (ex: AuditTable); minimum columns should be: TableName (varchar), RandomValue (float). Add a trigger on the AuditTable that will fire whenever a the RandomValue changes - this trigger's job will be to drop dynamically re-create the audit trigger for each table listed (TableName) in the AuditTable. The audit trigger (for each table) should insert into an AuditRecord table, which captures: the table name, primary key ID, action type (INSERT/UPDATE/DELETE), original field values and updated field values. If table structure changes, a simple update of the RandomValue in AuditTable will cause the triggers to re-generate. You will need to write the code that auto-generates the trigger for a given table; it is recommended that only 1 primary integer key is used on each table that is audited.

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

Я считаю, что базы данных в памяти с параметрами сохранения (например, H2) также должны делать то же самое. Но сам не пользовался.

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

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