Хранение хранения аудита

Question

Для хранения записей аудита в целях аудита я пытался записать, какие данные изменились.

В прошлом я делал два разных способа, но сейчас я создаю новую систему и пытаюсь выяснить, какую использовать:

1. Имеют таблицы AuditEntry и AuditEntryChange. Каждое измененное значение поля помещается в таблицу AuditEntryChange и имеет FK для AuditEntry.

2. Хранить измененные поля и значения в XML в таблице AuditEntry в одном поле.

Что из вышеперечисленного будет более эффективным для сохранения и запроса? (включая влияние сериализации / десериализации при использовании XML). А что займет меньше места?

Кроме того, рекомендуется ли использовать GUID или int PK для таблиц аудита? Я могу придумать причины для каждого.

Answer 1

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

Я бы склонялся к варианту 2 по следующим причинам:

• Вставка одной строки быстрее, чем вставка нескольких строк с ограничениями внешнего ключа.
• Наличие поля XML дает большую гибкость в структурировании данных аудита, не беспокоясь о схеме базы данных.
• SQL Server может запрашивать столбцы XML с использованием синтаксиса XPath, поэтому у вас все еще могут быть некоторые возможности реляционных запросов.
• Выбор многих записей, например, для отображения в форме, также выполняется быстрее, посколькунет присоединений.
• Эта модель может быть легко перенесена без хранения NoSQL.
• Сериализация XML будет задействована только при вставке из кода или загрузке обратно в код.Вы все еще можете запросить столбец XML напрямую через SQL.
• Я бы предположил, что требования к пространству увеличатся, хотя это зависит от размера индексов, которые могут возникнуть в результате реляционной модели.

Что касается int vs Guid для таблиц аудита, я бы пошел с Guid, потому что:

• При вставке с использованием ORM, например, NHibernate, после вставки нет выбора для получения сгенерированного идентификатора.Вы можете эффективно вставлять пакеты.
• Несмотря на то, что значение guid в 4 раза больше, для миллиона записей получается разница примерно в 10 МБ.Это действительно проблема?Тем более что маловероятно, что ПК запросит журнал аудита.
• Портировать на другие базы данных или механизмы хранения проще.

Answer 2

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

GUID в сравнении с целыми числами зависит от того, сколько записей вы собираетесь иметь в таблице. целое число занимает 4 байта против 16 байтов для GUID. Если вы хотите использовать межсерверное развертывание, хотя GUID намного проще.

Вот хорошая статья о плюсах и минусах.