ログテーブルはidフィールドまたは主キーを取得する必要がありますか？

特定のファイルが別のシステムにエクスポートされた日時スタンプを記録するログテーブルがあります。

現在、exportedLogテーブルには3つのフィールドがあります。

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

これを確認すると、idこのテーブルへの結合がないため、フィールドは何の役にも立たないことがわかりました。このテーブルで機能するのは、メッセージを処理してこのログテーブルに挿入するバッチジョブの挿入だけです。

idフィールドを削除する必要がありますか？

どちらかmessageId、exportedDateTimeまたは両方に主キーが必要ですか？

idフィールドを削除する必要がありますか？

保管することをお勧めします。

今はフィールドは必要ないかもしれませんが、将来的には本当に役立つでしょう-各ログエントリのファイルの詳細を保存する必要がある場合はどうでしょうか？

このテーブルがどれくらいの大きさになるか、そしてどれだけ速くなるかはわかりませんが、大きなテーブルに列を追加することは、通常、コストのかかる操作です。テーブルが比較的小さい場合、ストレージスペースの点で重要ではありません。IMO、列を保持し、潜在的な頭痛を後で保存します。

messageId、exportedDateTime、またはその両方に主キーが必要ですか？

messageIdこのテーブルでは単独では一意ではないように思えますが（間違っている可能性があります）、日付/時刻列のみで一意性を作成すると、重複（およびエラー）が作成される可能性があります。残っている唯一のオプションは2列のキーです。これは、上記で説明したシナリオを考えると、特に魅力的ではありません。

基本的に、この回答の私のポイントは、列を維持することは大した問題ではない（私は想定している）が、後でそれを必要とすることは大問題であり、元に戻すには追加の作業が必要になる可能性があるということです。

• このテーブルに結合がなく、更新も削除もない場合、キーはまったく必要ありません。

• これが当てはまらず、messageId一意である場合は、それを主キーにすることができます。

• 一意で(messageId, exportedDateTime)はないが一意である場合は、これを複合主キーにします。

• 場合でも(messageId, exportedDateTime)組み合わせが重複与えることができますし、更新をし、削除が必要になることがあります、あなたはより良いままにしたい（誤って挿入された行を削除すると言う）idであるとしてフィールドを。

主キーは問題になりません...ログ/監査証跡の目的を考慮する場合、それはおそらく問題の解決やデータの復元などのために将来的に使用（照会）され、おそらく他のものに結合されますそのような作業を実行するための既存の非ログ/監査テーブル。