SQL Serverテーブル設計のアドバイス

Question

これは愚かな質問かもしれません。

これらのサーバーは今後数カ月間で2014年にアップグレードされますが、SQL Server 2008 R2の効率に関するアドバイスもあります。私は3つのテーブルを作成しています。

• t1は、様々なタイプの多くの列と主キーであるアイデンティティの数値IDを持っています。私はこのテーブルが1000の低い行に入ることを期待しています。

• t2は、t1と1対多の関係にあります。主キーはt2 IDとt1 IDの複合です。 t2数値IDはフロントエンドアプリケーションによって送信され、t1 IDごとに一意になります。私はこのテーブルが50000+の行に到達することを期待しています。これらの2つのIDの他に、さまざまな長さのvarcharカラムがいくつか含まれています。

• t3は、t2と1対多の関係にあります。プライマリキーは、t3 ID、t1 ID、およびt2 IDのコンポジットです。再び、t3数値IDはフロントエンドアプリケーションによって送信され、t2 IDごとに一意になります。私はこのテーブルが数百万行に達することを期待しています。これらの3つのID以外に、少数の日付または数値列が含まれます。私はt3は、本質的にT3の主キーは、T3のIDとt2からのID列、つまり、2列の代わりに、3になることを意味するために参照するID列を設定する必要があります私の質問をt2内にある

。これはより効率的でしょうか？ t2内のこのID列にインデックスを付ける必要がありますか？ジョインを助ける？

私は何か他のことをしていますか？

Answer 1

私が最初に考えたの懸念声明

... [T2 | T3]の数値IDは、フロントエンドアプリケーション によって送信されます...

あなたはユニークな識別子を生成している場合データベースで使用するには、データベースに数値を生成させることをお勧めします。 になることができない限り、は重複IDを生成しません。

 
    +----+ +----+ +----+ 
    | | | | | | 
    | t1 +---+ t2 +---+ t3 | 
    | | | | | | 
    +----+ +----+ +----+ 

keys: t1.id t1.id t1.id 
       t2.id t2.id 
         t3.id 

代理キーへの変更は、それがt1（不要）を変更しません（私が正しくあなたのテーブル構造を理解している場合）サロゲートキーを使用しているときあなたのコメントに応えて

は、ここでの違いをです。 t2も同じままですが、t2.idを行番号から一意のプライマリキー[pk]に変更する必要があります。問題は、テーブルの別のフィールドとして '行番号'を保存する必要があることです。

主な違いは​​で、3つのテーブル識別子すべてではなく、t2.pkとそれ自身の行識別子のみが必要です。

 
     +----+ +----+ +----+ 
     | | | | | | 
     | t1 +---+ t2 +---+ t3 | 
     | | | | | | 
     +----+ +----+ +----+ 

keys: t1.id  t2.pk t2.pk 
       t1.id t3.pk 

この方が良いでしょうか？よく分かりません。また、テーブルに対して実行しているクエリのタイプと頻度にも依存します（ご質問のコメントを参照）。t2またはt1に参加しなくても、t3内の行を検索 -

idによってあなたは主に、クエリの場合、最初のレイアウトが最高になります。しかし、検索を行うために他のテーブルからの情報が必要な場合は、代理キー構造によって結合があまり冗長になることがあります。

最終的には、実装するまでは何が最良かを知ることができないため、これは最終的に（クエリのパフォーマンスに関して）時期尚早な最適化です。

Answer 2

私は通常、このためにID intプライマリキーを作成し、これをクラスタ化インデックスにします。

私は、t2またはt3に複合IDではなく、別のフィールドを持ち、外部キー制約を設定することはありません。

クラスタ化インデックスと外部キーは、必要なすべてのインデックス作成（結合用）になります。クエリに基づいて追加のインデックスが必要な場合があります。

私はこれを1億の行数のテーブルに設定し、1秒未満でクエリ結果を取得しました。