Должен ли я включить первичный ключ для таблицы аудита в SQL? - PullRequest
1 голос
/ 07 апреля 2009

Я создаю таблицу аудита для отслеживания изменений, выполненных в записи в основной таблице.

Здесь таблица аудита является точной копией основной таблицы (скажем, таблицы сотрудников), но будет иметь «вставки» только для каждого изменения в основной таблице. Так что у него будут дубликаты (одинаковые EmployeeID), поэтому я должен добавить отдельный Audit_ID для каждой записи?

Ответы [ 4 ]

3 голосов
/ 07 апреля 2009

Конечно, вам нужен какой-то первичный ключ в таблице.

Будет проще удалить дубликаты и отслеживать «причину вставки» (для целей отладки), если она у вас есть.

Некоторые RDBMS (например, MySQL с InnoDB) фактически создают скрытый первичный ключ для вас, если вы не сделали этого явно, поэтому просто сделайте это самостоятельно и сделайте, если он видим и пригоден для использования.

1 голос
/ 07 апреля 2009

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

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

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

Что также указывает на полезность добавления метки времени в таблицу аудита. Но не думайте, что вы должны использовать это и employeeid в качестве составного ключа. Во-первых, составные ключи отстой. Во-вторых, вполне возможно, что степень детализации временной метки меньше, чем время, которое потребуется вашей системе для выполнения двух обновлений (два обновления одного и того же сотрудника, как, скажем, в пакетной операции). (У даты-времени Sybase степень детализации составляет три миллисекунды; Intel Core 2 Extreme может выполнить за это время почти 200 миллионов инструкций.)

0 голосов
/ 07 апреля 2009

Да. Я считаю, что несемантический первичный ключ в каждой таблице - это лучшая практика, поскольку он позволяет вам ссылаться на него прагматическим образом. Вы можете визуализировать «изменения с audit-id до audit-id+1» гораздо проще, чем с помощью дат.

0 голосов
/ 07 апреля 2009

Вы можете использовать идентификатор сотрудника и дату и время аудита в качестве составного ключа ...

...