web-dev-qa-db-ja.com

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

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

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

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

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

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

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

database-designprimary-keylogs
12
kacalapy

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

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

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

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

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

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

本質的に、この回答の私のポイントは、keeping列は大した問題ではない（私は想定している）が、それを必要とするlaterは大問題である、および/または元に戻すには追加の作業が必要です。

10
Jon Seigel

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

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

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

  • (messageId, exportedDateTime)の組み合わせにより、重複が発生する可能性がありますand更新と削除が必要になる場合があります（誤って挿入された行を削除する場合など）。idフィールドはそのままにしておくことをお勧めします。

6
dezso

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

0
Mark E