3

関係する単語はリレーショナルデータベースの分野では一般的なものであるため、これを検索するのは難しいので、これが重複している場合は、正しい方向に向けてください。

「ホットスポット」テーブルがあるとします。ホットスポットは、任意の数のリンクテーブルに表示される可能性があるとします。すべてのリンクテーブルで不要なクエリを実行したくないので、「ホットスポット」タイプを指定して、最初に結果を取得し、特定のタイプのリレーションのみを検索できるようにします。

リンクテーブルの実際の名前を参照する「link_type」列を作成するのは悪い習慣ですか？たとえば、次のリンクテーブルがあるとします。

table link_hotspot_collectable
table link_hotspot_minigame
table link_hotspot_factoid

次のテーブルは、データの量/タイプが異なる一意のテーブルです。

table collectable
table minigame
table factoid

その場合、列「link_type」の可能な値は「collectable」または「minigame」になります（または、リンクテーブル名全体「link_hotspot_factoid」を使用できると思います」

これは良いアプローチですか？より簡単/より高速なクエリを形成するためのより効率的またはより優れたスキーマはありますか？

目的は、「ホットスポット」（ピクセルマップされた空間の幾何学的座標）を他のアクション/収集物/ゲームのセットで一般化することです。ゲームテーブルは、収集品テーブルのスキーマとは大幅に異なります。

4

1 に答える 1

1

以下のスキーマを検討してください（より簡単な方法で説明できるように、一般的な例に入れます）。

 ___________     _________     _____
|Cars       |   |Planes   |   |Parts|
-------------   -----------   -------
|-Id        |   |-Id      |   |-Id  |
|-RideHeight|   |-Wingspan|   |-Name|
-------------   -----------   -------
 ___________     ___________
|Plane_Parts|   |Car_Parts  |
-------------   -------------
|-PlaneId   |   |-CarId     |
|-PartId    |   |-PartId    |
-------------   -------------

私があなたが求めていると思うPartsのは、タイプ識別子を含めるように変更できるかどうかです。それにより、クエリがより速く/より簡単になりますか。

 ______
|Parts |
--------
|-Id   |
|-Name |
|-Type | (Plane, Car, etc.)
 ------

この新しいスキーマでは、次のようなことを希望します。「パーツIDがあり、パーツを見つけて、飛行機の場合は、車を見る代わりに飛行機の情報を照会します」。結果を考慮してください：

  • データベース内の情報を複製しました。元のモデルでは、結合テーブルは、どのタイプのパーツがどのタイプの車両に結合するかをすでに宣言しています。ここで、手動で設定する必要があり、チェックされていない方法で同じ情報を提供する別の列を追加しています。これは簡単に同期が外れ、簡単に回避できる頭痛の種になる可能性があります。

  • 1つのパーツを飛行機または車の両方に適用する機能を削除しました。元のスキーマには、飛行機や車で使用されるラジオが含まれている可能性がありますが、タイプフィールドを追加すると、この可能性が排除されます。これはスキーマには当てはまらないかもしれませんが、スキーマを理解しようとしている人にとっては混乱を招きます。残念ながら、「各パーツはテーブル内のレコードまたはCarsテーブル内のレコードにのみ結合できる」という制約はあり得ませんが、指定されたタイプの列はそれを保証しません。Planes

  • とにかくあなたが求めている結果を得るのはそれほど難しい/遅いことはありませんでした。関連するすべてのテーブルの結合は、クエリの2番目の部分を決定するswitchステートメントと同じように、SQLに精通している人には明らかです。コレクション全体をプルダウンしてから、別のクエリを実行して探している結果を取得する必要があるため、実際には説明した方法が遅くなる可能性があります。SQL Serverは、その場でそれを実行し、既存のインデックスに基づいて必要な結果を構築する可能性があります。

うまくいけば、これはあなたが説明しているものと似ています。Typeもしそうなら、型列を管理するのが難しいフィールドを追加することに何の利点もありません。これがあなたの説明と異なる場合は、私に知らせてください。この応答を修正できます。

于 2013-02-04T20:55:19.060 に答える