レコードのメタデータを保存するためのベストプラクティス

個々のレコードのメタデータをデータベースに保存するためのベストプラクティスは何ですか？

データベース内の多くのテーブルの作成時刻や最終更新時刻などの一般的なメタデータを保存する必要があります。私はいくつかの異なる解決策を見つけました：

1. メタデータをテーブルに直接保存します。

   長所：

   • メタデータはレコードに直接リンクされています
   • メタデータを取得するために結合は必要ありません

   短所：

   • 多くの重複列が必要です（継承が使用されている場合を除く）
   • メタデータとビジネスデータは分離されていません

2. で一般的なメタデータテーブルを作成し、ソフト外部キーを使用してデータを正しいテーブルとレコードにリンクします。

   長所：

   • 列の重複なし
   • メタデータはビジネスデータから分離されています

   短所：

   • メタデータとデータ間の直接リンクなし（FKは使用できません）
   • 結合には追加の条件が必要です

3. メタデータを必要とするテーブルごとに個別のメタデータテーブルを作成します。

   長所：

   • メタデータはレコードに直接リンクされています
   • メタデータはビジネスデータから分離されています

   短所：

   • 追加のテーブルがたくさん必要です
   • 多くの重複列が必要です（継承が使用されている場合を除く）

ここで述べたものよりも多くのオプション、長所または短所はありますか？そして、このメタデータを保存するためのベストプラクティスは何ですか？

あなたが話している列は20バイトを占めます（パディングなしで整列されている場合）：

作成時間、更新時間、作成ソース

タイムスタンプ.. 8バイト
タイムスタンプ.. 8バイト
整数.. 4バイト

別のテーブルの別の行のタプルヘッダーとアイテムポインターだけが、23 + 1 + 4 = 28バイト+ 20バイトの実際のデータと最後に4バイトのパディングを占有します。なる行当たり52バイト。詳細はこちら：

• 読み取りパフォーマンスのためのPostgreSQLの構成

ストレージに関しては、何も得ることができません。パフォーマンスに関しては、行ごとに16〜24バイト多いだけでほとんど何も失うことはありません。

列も行に直接属しているため、それらを一緒にしておくことは理にかなっています。私は、関連するすべてのテーブルにそのような列（および最後の更新用の個別のソース）を正確に追加することを習慣にしています。

またTRIGGER ON INSERT OR UPDATE、それらを最新に保つためにを書くのも簡単です。

簡単に言えば、あなたの選択に対する強い投票1。

どこで私は行くだろうオプション3：
コア行がないときに、メタデータは、頻繁に更新された場合。次に、UPDATEをより安くしてメインテーブルの膨らみを減らすために、個別の1：1テーブルを維持することは有料になるかもしれません。

どこで私はのために行くだろうオプション2：
メタデータ列のセットは非常に反復的である場合。メインテーブルのメタデータのセットにFK列を含めることができます。あなたの例のように、3つの小さな列についてはあまり保存しません。