Должна ли таблица журнала получить поле идентификатора или первичный ключ?

У меня есть таблица журнала, которая фиксирует дату и время, когда определенные файлы были экспортированы в другую систему.

В настоящее время таблица exportedLog имеет три поля:

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

Изучив это, я обнаружил, что idполе не имеет смысла, так как в этой таблице нет соединений. Единственное, что работает с этой таблицей - это вставка пакетного задания, которое обрабатывает сообщения и вставляет в эту таблицу журнала.

Должен ли я удалить idполе?

Должен ли я иметь первичный ключ либо messageIdили exportedDateTimeили оба?

Должен ли я удалить поле id?

Я бы порекомендовал сохранить его.

Вам может не понадобиться поле сейчас , но в будущем оно действительно может вам помочь - что, если вам нужно будет хранить данные о файлах для каждой записи журнала?

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

Должен ли я иметь первичный ключ в messageId или exportedDateTime или в обоих?

Это не звучит так, как если messageIdбы один был уникален в этой таблице (хотя я могу ошибаться), и создание уникальности только для одного столбца даты / времени может потенциально создать дубликаты (и, следовательно, ошибки). Единственный оставленный вариант - это ключ с двумя столбцами, который не особенно привлекателен, учитывая сценарий, который я изложил выше.

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

• Если у вас нет объединений в этой таблице, нет обновлений и удалений, тогда вам вообще не нужны ключи.

• Если это не так и messageIdявляется уникальным, вы можете сделать его первичным ключом.

• Если он не уникален, но (messageId, exportedDateTime)есть, то сделайте его составным первичным ключом.

• Если даже (messageId, exportedDateTime)комбинация может дать дубликаты и обновление , и могут потребоваться удаления (скажем , для удаления случайно вставленные строк), то лучше оставить idполе как есть.

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