SQL - дизайн таблицы журнала аудита - что бы вы предпочли? - PullRequest
Новая
       2

SQL - дизайн таблицы журнала аудита - что бы вы предпочли?

3 голосов
/ 18 февраля 2011

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

Мое предложение для этого было следующими таблицами схемы и отношениями (пример): 

Table AuditLog
------------------------------
Id | PK
Description
Created

И для каждой задачи: 

Table ExampleTaskAuditLog
------------------------------
ExampleTaskId | FK PK
AuditLogId | FK PK

И: 

Table AnotherExampleTaskAuditLog
------------------------------
AnotherExampleTaskId | FK PK
AuditLogId | FK PK

По сути, для каждого вида задач, которые нам нужны для аудита, у нас будет новая таблица, содержащая взаимосвязь.

То, что предложил другой разработчик, было следующим:

Table AuditLog
------------------------------
Id (PK)
Description
Created
ExampleTaskId | NULLABLE
AnotherExampleTaskId | NULLABLE
Type | (an integer id which indicates whether this is a "example task" or a "another example task").

По сути, если бы мы создавали журнал для «ExampleTask», мы установили бы поле ExampleTaskId в качестве идентификатора примерной задачи, а тип - в соответствующее значение ExampleTask-enum.*

Он предложил приведенную выше таблицу, потому что он спорит о честности (что я считаю хорошим!) И производительности.Главным образом потому, что есть ограничения FK, и нужно было бы объединить таблицу, чтобы получить соответствующие журналы (да, это RMDBS - MSSQL).Кроме того, поскольку для каждого журнала есть две таблицы, необходимо также две вставки (поиск целостности и т. Д.).Конечно, это правильно.Но я не вижу проблемы.Особенно не с производительностью, так как она минимальна.Кроме того, журналы, которые будут сохранены, скорее всего, не будут превышать 5-10K в течение первого года.Через пару лет таблицы могут содержать около 30-40 тыс. Строк, максимум

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

Ответы [ 2 ]

2 голосов
/ 18 февраля 2011

Я не уверен, что полностью понимаю - если ExampleTaskId и AnotherExampleTaskId имеют одинаковый тип данных, то почему бы просто не иметь одну таблицу со следующими столбцами?

  • Id
  • Описание
  • Создано
  • TaskId
  • TaskType

Кроме того, ваша AuditLog таблица определенно должна иметь поле TaskType, так как в противном случае становится относительно трудно определить, какой тип изменения представляет запись в журнале.

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

Table ExampleTaskAuditLog
------------------------------
AuditId (PK)
TaskSpecificField
AnotherTaskSpecificField
0 голосов
/ 18 февраля 2011

Предполагая, что вы регистрируете события / задачи / действия, а не изменения в отдельных таблицах, я бы остановился на первой, по тем же причинам, говорит @Kragen (upvoted). Но если вы проверяете изменения отдельных таблиц, я бы выбрал одну таблицу аудита для каждой проверяемой таблицы.

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

...