1

私は、ユーザーがオプションの種類で検索してコンピューターを見つけることができる、かなり単純なシステムを実行しています。ブランド、型式、「オプション」で検索したい。

基本的に、このシナリオには5つのテーブルがあります-

  1. ブランド
  2. モデル
  3. 選択
  4. options_group
  5. オプション

選択テーブルは、以下を含む複数列のルックアップ テーブルです。

  • brand_id
  • モデル ID
  • options_group_id

options_group テーブルは、「オプションのグループ」の ID と各 option_id のエントリを持つルックアップ テーブルです。

基本的に、options_group テーブルを使用すると、多数のエントリが複数回保存することなく、同じオプション グループを持つことができます。

右。そう。テーブルを生成する特定のパーツを選択したい:

  • ブランド
  • モデル
  • オプション

ここで、「オプション」は options_group に基づいて生成されます。

私の質問は次のとおりです。最初に選択テーブルからのみ選択し、次に options_group を使用して 2 番目の選択を行い、各行のすべてのオプションを取得する、複数の選択ステートメントでこれを行うか、または結合を行いますか?たくさんの行を持つテーブルを取得しますか?

あなたがそれを提案する前に、SOに関する他の回答がこの正確な質問に答えているとは思いません。

または、それを行うための他のより良い方法はありますか？結合は複数の選択よりも桁違いに速いと読みましたが、最後に解析するには時間がかかる可能性があります。

4

2 に答える 2

1

単一のステートメントを使用しselect distinctて重複を除外します。SQL の基礎となる関係計算/関係代数は、project演算子の一部として重複を自動的に排除します。ただし、SQL はデフォルトではそうしないため、 を使用する必要がありますdistinct。基礎となるリレーショナル理論は単一のステートメントを推奨し、演算子にうまく適合するため、ベスト プラクティスとしてお勧めします。

2つのテーブルparent (id)でchild (id, parent_id, property)select distinct parent.id from parent join child on parent.id = child.id where child.property in ("X", "Z");

于 2013-05-21T00:34:53.953 に答える
1

あなたが良い実践を求めたので、これがデータベースのみの解決策である必要はないという事実を投げかけます。静的/ルックアップ データ (モデルやパーツがあまり頻繁に変更されないように聞こえます) をアプリ レイヤーまたは memcached などにキャッシュすることをお勧めします。これにより、結合が節約され、結果セットのサイズが縮小されます。

于 2013-05-21T00:59:39.527 に答える