私は 7 つの内部結合を持つクエリを持っています (多くの情報が他のテーブルに分散されているため)。何人かの同僚が驚いています。彼らは驚くべきなのか、それとも 7 つの内部結合が正常なのか疑問に思っていました。
7596 次
14 に答える
25
前代未聞ではありませんが、使いやすさとメンテナンスのためにビューに配置します
于 2008-10-31T19:04:07.607 に答える
17
2 つの質問:
- それは機能しますか？
- 説明できますか？
だったらセブンでいいじゃん。クエリを説明できない場合は、7 つでは多すぎます。
于 2008-10-31T19:04:31.163 に答える
5
スキーマが第 5 正規形であれば正常です:)
于 2008-10-31T19:03:41.227 に答える
4
達成しようとしていることに応じて、クエリ内の多数の結合は注目に値しません。
個人的には、目的の結果セットを返すために使用される結合の数よりも、クエリが最適化され、許容可能なパラメーター内で実行されているかどうかに関心があります。
クエリが完全に最適化されており、トリミングできないが、クエリ自体が十分に速く実行されない場合は、データ構造の設計が目的に適合していない可能性があります。その時点で、何を達成しようとしているのか、またはビジネス モデルに供給されているデータの構造を再評価できます。
于 2008-10-31T19:05:51.643 に答える
3
それはまったく珍しいことではありません。Siebel のようなシステムでは、結合数が 2 桁になるのが一般的です。
于 2008-10-31T19:06:15.717 に答える
3
結合が 7 つあると、読みやすさが難しくなりますが、パフォーマンスとスケーラビリティがより重要になります。それらがOKなら、それのために行きます。
于 2008-10-31T19:06:15.747 に答える
2
ファクト テーブルが 12 のディメンションへの外部キーを簡単に持つ可能性があるデータ ウェアハウスでは、7 つまたはそれ以上であることはまったく珍しいことではありません。データ ウェアハウスのシナリオでは、ディメンションのカーディナリティは通常、ファクト テーブルと比較して低いため、ディメンションに対するフィルターは、インデックスのシークまたはスキャンを通じてファクト テーブルを利用するのに役立ちます。
正規化されたトランザクション スキーマの場合、プライマリ ベース テーブルで結果セットのカーディナリティが低い場合 (つまり、1 人の顧客に関するすべてを選択する場合) は、通常は問題になりません。これは、通常、外部キーによって単純にインデックス シークまたはインデックス スキャンが発生する可能性があるためです。
于 2008-11-01T01:13:12.230 に答える
2
それはおそらく正常ではありませんが、確かに過剰ではありません。同じテーブルを何度も結合している場合は、いくつかのビューを作成してください。
于 2008-10-31T19:05:59.833 に答える
2
結合の数はデータ モデルによって異なります。それがクエリの対象である場合は、7 つの結合をクエリに含めることができます。以前に作業したアプリで同様のクエリを使用したことを思い出します。パフォーマンスは多くの要因 (テーブル サイズ、インデックス) に依存します。 、サーバーの負荷、サーバーの構成をいくつか挙げると、7 つの結合が悪いという一般化はできないと思います。
それがあなたのために働くなら、私はそれでいいと思います:D
于 2008-10-31T19:06:39.490 に答える
2
はい、それは正常ですが、実際には、パフォーマンスの観点からはそれほど優れたアイデアではありません。クエリ プランは推定コストに基づいて構築されるため、結合 (またはその他の演算子) を増やすと、エラーの数が増加します。
SQL Server クエリ オプティマイザーは、シーク演算子から出てくる最低 1 つの行を推定します。これは、カーディナリティの過小評価のために非常に高価なサブツリーが選択されるケースを回避するために行われます。サブツリーがゼロ行を返すと推定される場合、多くのプランのコストはほぼ同じであり、結果としてプランの選択でエラーが発生する可能性があります。したがって、この場合の見積もりは「高く」、エラーが発生する可能性があることに気付くでしょう。また、実際の 10 回ではなく、この分岐の 20 回の実行を見積もっていることに気付くかもしれません。ただし、この演算子の前に評価された結合の数を考えると、2 倍 (10 行) ずれているとは見なされません。残念な。(エラーは、結合の数に応じて指数関数的に増加する可能性があります)。
また、オプティマイザーは、計画を立てるのに必要な時間と潜在的な節約のバランスをとろうとします。最適な計画を見つけるために一日中費やすことはありません。結合が多いほど、代替計画の数が多くなり、そのうちのいくつかは、オプティマイザが検出する時間よりも最適である可能性があります。
于 2008-10-31T20:12:17.657 に答える
1
データベース設計で必要な場合は、7 で問題ありません。ただし、目標を達成するために 7 が必要な場合は、データベースの設計を再検討して、このレベルのあいまいさが本当に必要であることを確認します。
好奇心から、これは DB2 ですか? 私が気づいたちょうどパターン:)
于 2008-10-31T19:12:38.760 に答える
1
これは、同じテーブルに対する 7 つの内部結合、異なるテーブルに対する 7 つの内部結合、またはネストされた7 つの内部結合ですか?
...ひっかけ質問！データベース構造が必要とするものであれば問題ありません。それは正しいことです。
注意: 同じテーブルに 7 つのネストされた内部結合がある場合は、おそらくテーブルの構造が不十分です ;-)
于 2008-10-31T19:28:35.687 に答える
1
それは確かに珍しいことではありません。ただし、少なくとも Oracle では、7 は特別な数です。7 を超えると、オプティマイザはすべての結合順序をテストできなくなります (可能性の数が階乗的に増加するため)。したがって、実行計画を子守する準備ができていない限り、7 を超えないようにするのが賢明です。
于 2008-10-31T20:15:14.313 に答える
0
回避したいのは、結合の深さが 7 を超えることだと思います。深さが 7 未満の結合の 7 つの内部結合は確かに前代未聞ではありませんが、「7 結合」と聞いて、7 結合がノーノーだと考える人もいます。深さではありません。
于 2008-10-31T19:08:05.180 に答える