0

私は、パフォーマンスが最優先事項であるWebサイトのデータベースを設計しています。

主な機能は2つのテーブルに基づいています。

そして、これらのテーブルには多対多の関係があります。

これを分割するために、関係ごとに両方のテーブル主キーの組み合わせを保持するテーブルTable1_Table2を追加しました。

たとえば、すべての車が車のテーブルにあり、すべての色がカラーテーブルにあります

CarTable

ID（PK）-名前

1- BMW2-
メルセデス
3
-VW4-アウディ

ColorTable

ID（PK）-色

1-青
2-緑
3-黒
4-黄色

多対多の関係のために、私はこれを行いました：

Car_ColorTable

ID（PK）-CarID-ColorID

1-1 --2
2 --1 --4 3 --2
--4 4 --3 --1 5-4 --1 6-4 --3 7-4-3



これは、次のことを考慮した優れた設計ですか。

1）パフォーマンスが最優先事項です。

2）テーブルには膨大な量のデータが含まれます（両方のテーブルに100万を超えるレコードがあり、Car_ColorTableに最終的にいくつの行が含まれるかを想像できます。

上記の設計が解決策でない場合、これをどのように設計すればよいですか？

4

5 に答える 5

3

Car_ColorTableである必要があります

CarID (PK) - ColorID (PK)

そこにid列は必要ありません。主キーには 、（ColorID、CarID）を意味する逆の順序の列を使用して、同様の非クラスター化インデックスを作成できる 両方
の列が必要です。

于 2013-01-28T14:30:14.283 に答える
2

これは、関係をマッピングするための最良の方法です。通常、どのオブジェクトからリレーションにアプローチしようとし、クラスター化インデックスをその列に配置するかを確認してください。

結合されたPKを作成することもできますが、重複を使用することはできません。

于 2013-01-28T14:33:40.997 に答える
1

おそらく、 SELECTのパフォーマンスが最も重要であると言うつもりでした。ただし、SELECTのパフォーマンスがデータの整合性よりも優先されるようにすることはできません。間違った答えを本当に速く得ることは決して良い要件ではありません。

代理キー（整数）を使用する場合、主キーは。である必要がありますprimary key (car_id, color_id)。追加の代理キー「ID」はここでは役に立たず、通常はSELECTのパフォーマンスを低下させます。（より多くの列、より広い行、ディスク上のデータページあたりのより少ない行、より多くのディスクI / O。）

自然キー（車の名前と車の色）と代理キーの両方でテストする必要があります。代理キーには、クエリごとに2つの結合が必要です。自然キーは結合を必要としません。代理キー（車、色）を使用するテーブルでも、名前に一意の制約が必要です。「青」には13の異なるID番号があることを後で発見したくありません。

1〜2時間かけてスクリプトを作成し、代理キーがある場合とない場合で数百万行を生成し、パフォーマンスを比較します。

于 2013-01-28T14:36:16.867 に答える
1

あなたのデザインは素晴らしいようです。覚えておくべきこと：

  1. インデックスはあなたの友達です。それらを使用してください。
  2. パフォーマンスについて話すときは、通常、読み取りパフォーマンスを向上させると、更新/挿入書き込みのパフォーマンスがわずかに低下することに注意してください。

100万レコードは実際にはそれほど多くはなく、高速クエリを実行できます。十分な処理能力とメモリを備えたまともなサーバーを入手すれば、問題はないはずです。

于 2013-01-28T14:37:24.550 に答える
0

テーブルに関しては、Car_ColorTable実際に同じ車と色の間で複数の接続を許可したい場合、またはその他の特別な理由がない限り、代理キー{Id}をドロップして、車と色の組み合わせである自然キーを使用してください。

どの程度正確に実行するかは、実行する必要のあるクエリによって異なります。

  • 必要な場合：「特定の車について、色を教えてください」で、に複合クラスター化された主キーを作成し{CarID, ColorID}ます。
  • 「特定の色に対して、車をください」が必要な場合は、に複合クラスター化された主キーを作成します{ColorID, CarID}。
  • 両方が必要な場合は、に主キーを作成し{CarID, ColorID}、に副インデックスを作成し{ColorID, CarID}ます。
    • 表示していない追加のフィールドがない限り、PKをクラスター化します。
    • 追加のフィールドがある場合は、非クラスター化（つまり、ヒープベース）テーブルを使用するか、すべてのフィールドをこれら2つのインデックスでカバーします（ INCLUDEキーワードが便利な場合があります）。
于 2013-01-28T21:06:05.233 に答える