レコードのメタデータを保存するためのベストプラクティス
個々のレコードのメタデータをデータベースに保存するためのベストプラクティスは何ですか？
データベース内の多くのテーブルの作成時刻や最終更新時刻などの一般的なメタデータを保存する必要があります。私はいくつかの異なる解決策を見つけました：
メタデータをテーブルに直接保存します。
長所：
- メタデータはレコードに直接リンクされています
- メタデータを取得するために結合は必要ありません
短所：
- 多くの重複列が必要です（継承が使用されている場合を除く）
- メタデータとビジネスデータは分離されていません
で一般的なメタデータテーブルを作成し、ソフト外部キーを使用して、データを正しいテーブルとレコードにリンクします。
長所：
- 列の重複なし
- メタデータはビジネスデータから分離されています
短所：
- メタデータとデータ間の直接リンクなし（FKは使用できません）
- 結合には追加の条件が必要です
メタデータを必要とするテーブルごとに個別のメタデータテーブルを作成します。
長所：
- メタデータはレコードに直接リンクされています
- メタデータはビジネスデータから分離されています
短所：
- 追加のテーブルがたくさん必要です
- 多くの重複列が必要です（継承が使用されている場合を除く）
ここで述べたものよりも多くのオプション、長所または短所はありますか？そして、このメタデータを保存するためのベストプラクティスは何ですか？
あなたが話している列は、20バイトを占有します（パディングなしで配置されている場合）：
作成時間、更新時間、作成ソース
タイムスタンプ.. 8バイト
timestamp .. 8バイト
整数.. 4バイト
別のテーブルの別の行のタプルヘッダーとアイテムポインターは、23 + 1 + 4 = 28バイト+ 20バイトの実際のデータと最後に4バイトのパディングを占有します。行ごとに52バイトを作成します。詳細はこちら：
ストレージに関しては、何も得ることができません。パフォーマンスに関しては、行ごとに16〜24バイト多いだけでほとんど何も失うことはありません。
列も行に直接属しているため、それらを一緒にしておくことは理にかなっています。私は、すべての関連テーブルにそのような列（および最後の更新用の個別のソース）を正確に追加することを習慣にしています。
また、TRIGGER ON INSERT OR UPDATEを記述して最新の状態に保つ方が簡単です。
長い話：オプション1への強い投票.
オプション3をどこに行こうか：
メタデータが頻繁に更新されているが、コア行はそうでない場合。次に、UPDATEをより安くしてメインテーブルの膨らみを減らすために、個別の1：1テーブルを維持することは有料になるかもしれません。
オプション2をどこに行こうか：
メタデータ列のセットが非常に反復的である場合。メインテーブルのメタデータのセットにFK列を含めることができます。あなたの例のように、3つの小さな列についてはあまり保存しません。