ファクトテーブルの主キー：代理キーまたは複数列の自然キー？
ファクトテーブルの主キー（簡潔にするためにPK）を選択する際のベストプラクティスは何ですか。自動インクリメントされたサロゲートキー（SK）が必要ですか、それともナチュラルキー（NK）列を使用する必要がありますか？
私がSKを使用することで得られる利点はINSERTのパフォーマンスです。これは、毎日100万行近くが挿入されている場合に非常に重要です。 1日あたり約2,000万行、1か月あたり約2億行を期待しています。テーブルは分割することなく、何十年もの間データを維持する必要があります。
ただし、NKをPKとして持ち、PKの順序が適切に設計されている場合、クエリのパフォーマンスは向上するはずです。
もちろん、クエリ用の非クラスター化インデックスを作成することもできますが、これはストレージを消費し、INSERTをさらに遅くします。
INSERTとDELETE（そうです、データが再処理され、新しいファイルのバージョンを "更新"する必要があるため、これもたくさんあります）を考慮すると、クエリのパフォーマンスとほぼ同じくらい、パフォーマンスは非常に適切です。
考慮すべき他の問題は、行が削除されてもSKカウントが減少しないことです。 1か月あたり2億行の場合、年間2,4G行になるため、intデータ型では保持できないため、PKにはbigintを使用する必要があります...
コンテキストは何ですか？データウェアハウスについて話しているようです。その場合は、合成キーを作成することを強くお勧めします。私は3つの正当な理由を考えることができます。
- ビジネスキーよりも狭くなります。ファクトテーブルに列を追加することは簡単ではありませんが、他のインデックスが狭くなるため、実際にはデータベースの合計サイズが減少する可能性があります。
- 自然キーが汚れます。遅かれ早かれ、誰かが関連のない何かのために製品コードを再利用するか、サブ顧客の追跡を開始する必要があります。自然キーと合成キーの間のマッピングプロセスがある場合、これらの種類のことを説明するのは簡単です。
- これを使用して、合成値を格納できます。「該当なし」の場合は-1、「不明」の場合は0、「不明」の場合は1、「不明」の場合は2など。自然キーによっては、そこにも同じですが、常に衝突の危険があります。
480億を超えるレコードは膨大です。まだの場合は、おそらく今月以降のデータの集計を検討する必要があります。合成キーもこれを単純化できます。おそらく値1,000,000,001..1,999,999,999は2017/08の詳細のために予約されており、10月に8月のデータはID 1,000,000,000の単一のレコードに折りたたまれます（これはおそらく良いアイデアではありません。ビジネスキーをウェアハウスキーから切断する方法の例）。
最後に、PKとクラスタリングキーの選択が同じである必要はないことを忘れないでください。それぞれを独自のメリットで評価する必要があります。
スタースキーマのファクトテーブルでは、合成キー（サロゲート、自動インクリメント）は役に立ちません。ファクトテーブル内のすべての外部キーの組み合わせは、perforceの候補キーです。そうしないと、星の形がよくありません。必要に応じて、それを主キーとして宣言できます。私はこれを選択します。
ただし、スターを定期的に更新するためのすてきなタイトなETLプログラムがある場合は、実際には主キーをまったく宣言せずに回避できます。
私はあなたがパフォーマンスに関して言ったことをエコーします。