Чи повинна таблиця журналу отримувати поле ідентифікатора чи первинний ключ?

У мене є таблиця журналів, яка фіксує штамп часу, коли певні файли були експортовані в іншу систему.

В даний час таблиця експортованих журналів містить три поля:

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

Переглядаючи це, я виявив, що idполе не виконує мети, оскільки до цієї таблиці немає приєднань. Єдине, що працює над цією таблицею - це вставка пакетного завдання, яке обробляє повідомлення та вставляє в цю таблицю журналів.

Чи потрібно видалити idполе?

Повинен чи я мати первинний ключ або messageIdабо exportedDateTimeабо обидва?

Чи потрібно видалити поле id?

Я б рекомендував зберігати його.

Це поле вам може не знадобитися зараз , але в майбутньому воно може справді допомогти вам - що робити, якщо вам потрібно зберегти дані про файли для кожного запису журналу?

Я не знаю, наскільки велика буде ця таблиця і як швидко, але додавання стовпця до великої таблиці - це зазвичай дорога операція. Якщо стіл порівняно невеликий, то зберігати з точки зору місця для зберігання не надто багато. IMO, збережіть стовпчик і збережіть потенційний головний біль пізніше.

Чи повинен я мати первинний ключ або на messageId, або експортуєтьсяDateTime або на обох?

Це не здається, що messageIdпоодинці було б унікально в цій таблиці (хоча я можу помилятися), а створення унікальності лише в стовпці дата / час потенційно може створювати дублікати (і, отже, помилки). Залишився єдиний варіант - 2-стовпчастий ключ, який не особливо привабливий, враховуючи сценарій, який я виклав вище.

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

• Якщо ви не маєте приєднань до цієї таблиці, жодних оновлень та жодних видалень, то вам взагалі не потрібні ключі.

• Якщо це не так і messageIdє унікальним, то ви можете зробити це первинним ключем.

• Якщо це не унікально, але (messageId, exportedDateTime)є, то зробіть це складеним первинним ключем.

• Якщо навіть (messageId, exportedDateTime)комбінація може давати дублікати та оновлення та можуть бути потрібні видалення (скажімо, для видалення випадково вставлених рядків), краще залишити idполе таким, яким воно є.

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