Haruskah tabel log mendapatkan bidang id atau kunci utama?

Saya memiliki tabel log yang menangkap cap datetime ketika file tertentu diekspor ke sistem lain.

Tabel dieksporLog saat ini memiliki tiga bidang:

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

Meninjau hal ini, saya menemukan bahwa idbidang ini tidak memiliki tujuan, karena tidak ada gabungan ke tabel ini. Satu-satunya hal yang bekerja pada tabel ini adalah menyisipkan pekerjaan batch yang memproses pesan dan menyisipkan ke dalam tabel log ini.

Haruskah saya menghapus idbidang?

Haruskah saya memiliki kunci utama pada salah satu messageIdatau exportedDateTimeatau keduanya?

Haruskah saya menghapus bidang id?

Saya akan merekomendasikan untuk menyimpannya.

Anda mungkin tidak membutuhkan bidang sekarang , tetapi di masa depan, ini benar-benar dapat membantu Anda - bagaimana jika Anda perlu menyimpan detail file untuk setiap entri log?

Saya tidak tahu seberapa besar tabel ini akan didapat dan seberapa cepat, tetapi menambahkan kolom ke tabel besar biasanya merupakan operasi yang mahal. Jika meja relatif kecil, maka itu bukan masalah besar untuk tetap dalam hal ruang penyimpanan. IMO, simpan kolomnya dan simpan potensi sakit kepala nanti.

Haruskah saya memiliki kunci utama pada messageId atau dieksporDateTime atau keduanya?

Itu tidak terdengar seperti messageIdsendirian akan menjadi unik dalam tabel ini (meskipun saya bisa saja salah), dan menciptakan keunikan pada kolom tanggal / waktu saja berpotensi dapat membuat duplikat (dan karenanya kesalahan). Satu-satunya pilihan yang tersisa adalah kunci 2 kolom, yang tidak terlalu menarik mengingat skenario yang saya sebutkan di atas.

Pada dasarnya, poin saya dari jawaban ini adalah bahwa menjaga kolom bukanlah masalah besar (saya berasumsi), tetapi membutuhkannya nanti mungkin merupakan masalah besar dan / atau membutuhkan kerja ekstra untuk mengembalikannya.

• Jika Anda tidak memiliki gabungan pada tabel ini, tidak ada pembaruan dan tidak ada penghapusan, maka Anda tidak perlu kunci sama sekali.

• Jika ini bukan kasusnya, dan messageIdunik, maka Anda dapat menjadikannya sebagai kunci utama.

• Jika tidak unik, tetapi (messageId, exportedDateTime)benar, maka buat ini sebagai kunci utama komposit.

• Jika bahkan (messageId, exportedDateTime)kombinasi dapat memberikan duplikat dan pembaruan serta penghapusan mungkin diperlukan (katakanlah untuk menghapus baris yang disisipkan secara tidak sengaja), Anda sebaiknya meninggalkan idbidang apa adanya.

Kunci Utama tidak akan sakit ... jika Anda mempertimbangkan tujuan jejak log / audit, kunci itu mungkin akan digunakan (tanya) di masa depan untuk menyelesaikan masalah atau memulihkan data, dll. Dan kemungkinan akan digabungkan dengan yang lain tabel non-log / audit yang ada untuk melakukan pekerjaan semacam itu.