パーティションキーもプライマリキーの一部である必要がありますか？

主キーではない列に基づいてテーブルをパーティション分割していますか？今日、パーティション列を主キーの一部にする必要があるかどうかに関するいくつかの矛盾する情報を読みました。私の腸はノーと言うが、私は100％確信していない。だから質問...

1. パーティション列はプライマリの一部である必要がありますか？どちらの方法がお勧めですか？
2. パーティションキーのインデックスを作成する必要がありますか、それともDBMSが自動的にインデックスを作成しますか？

どういたしまして。

パーティショニングの最も一般的なシナリオの1つは、PKとはまったく関係のない日付フィールドを使用することです。

たとえばOrders、フィールドOrderDateを含むテーブルがある場合、ほとんどの場合、月と年に基づいてパーティションを作成しOrderDateます。

レコードが古くなって関連性がなくなったら、それらのパーティションをアーカイブテーブルまたはデータベースに移動して、処理されないようにすることができます。

パーティショニングはほとんどすべてのフィールドで機能しますが、それがうまく機能するためには、すべてではないにしてもほとんどのクエリで、パーティション化したフィールドを使用する必要があります。パーティションキーを含めないと、本質的に複数のテーブル（パーティション）をスキャンする高価なテーブルスキャンが発生します。

編集

パート2では、答えはノーだと思います。パーティションキーは、行を配置するパーティションを決定するために使用されますが、インデックスが維持されるとは思いません。ただし、バックエンドに統計がある場合があります。

JNKの答えに加えて、おそらくテーブルパーティションとインデックスパーティションの調整について説明しているこの記事を読む必要があります。

パーティション化スキームが主キーの最初の列に正確に従うシナリオは多くの種類があります。たとえば、ファクトテーブルのスナップショットの日付が通常パーティションキーであり、主キーの最初の列であるデータウェアハウスシナリオなどです。

しかし同様に、PKがIDENTITYキーまたは他の代理キーであるOLTP環境では、通常、任意の番号でのパーティション分割はそれほど有用ではないため、パーティションにこれを使用する意味はほとんどありません。OLTPシステムでは、日付ごとに（おそらくPK内ではなく）パーティション分割する傾向がありますが、地域または何らかの種類の組織区分（サロゲートを使用していない場合はPK内）によってもパーティション分割する傾向があります。

しかし、それは要件ではありません。

主キー自体の一部でない場合、候補キーの一部である必要があります。考えてみて、あなたのパーティショニングはそれ自体を主キーに合わせる必要があります。

答えは、はい、PKの一部であることが望ましいです。別のキーではない場合、これはPKとして十分に優れています。