38

たとえば、クエリに 5 つ以上の左結合がある場合、そこにコードの匂いがします...

  • あなたのデザインに何か問題がありますか？
  • 1 つのクエリでやりすぎていませんか?
  • データベースが正規化されすぎていますか？
4

8 に答える 8

40

これは、一部の設計では完全に正当なソリューションです。

Customer- Order- Basket- Item-などのような 1 対多の関係の階層があるとしますPrice。これはどのレベルでも埋められない可能Customer性がありOrdersます。OrderBaskets

この場合、次のようなものを発行します。

SELECT  *
FROM    Customer c
LEFT OUTER JOIN
        Order o
ON      o.CustomerID = c.ID
LEFT OUTER JOIN
        Basket b
ON      b.OrderID = c.ID
…

場合によっては非効率的である可能性があり、EXISTSorに置き換えることができることに注意してくださいNOT EXISTS(対応するレコードが他のテーブルに存在するかどうかだけを知りたい場合)。

パフォーマンスの詳細については、私のブログのこの記事を参照してください。

于 2009-04-27T14:08:24.960 に答える
3

いいえ、まったくありません。一部のクエリで多数の左​​結合を使用するデータベース設計を構築することは完全に合法です。

経験上、外部結合を使用する（複雑な）クエリはエラーが発生しやすく、メンテナンスの問題が発生する可能性があるため、外部結合が必要なケースの数が制限されるように、データベースを構築することをお勧めします。

興味深い歴史的なことはさておき、IBMのDB2の初期バージョンは、メインフレームのみで実行されていた場合、外部結合をサポートしていませんでした（OracleとIngressはどちらも、当時は大きなセールスポイントでした）。これにより、データベースの予想されるすべてのデータアクセス要件を内部結合だけで解決できるようにする必要があるため、データベース設計にいくつかの興味深い問題が発生します。

于 2009-04-27T14:15:53.117 に答える
3

多くの結合 (正規化されたデータの処理など) を使用する必要があるのは、コードのにおいではなく、適切な場所で作業していない可能性があることを示していると私は主張します。私の経験では、クエリ内の結合の数を懸念している人は、データベースでの開発が多すぎて、データを公開するアプリケーションやレポートで十分ではありません。データ構造は、無数の用途をサポートするのに十分柔軟でなければなりません。これが、ある程度の正規化が重要である理由です。

今日のエンタープライズ アプリケーションを構築する際、開発者は以前の成果を活用して、より少ない作業でより多くの価値を提供するために、SQL や XML などのテクノロジよりも高い抽象的なレベルで作業できます。レポート ライター、コード ジェネレーター、ORM、エンティティ フレームワークなど、SQL を手動で構築する低レベルの作業を抽象化し、結合を実行するツールがあります。ほとんどの人は、使用されている SQL ダイアレクト (たとえば、Oracle 9 と MySQL 3) を認識しており、そのダイアレクトに対して最も効率的な SQL 構文を生成できます。つまり、彼らはおそらくあなたよりもうまく結合を作成できるということです。

ただし、これらのツールは、十分な正規化が行われていないリレーショナル環境では、ほとんど機能しないか、まったく機能しません。私にとって、これは「開発」の匂いが現れる場所です。確立されたデータ アクセス ツールが、データを構造化した関係を理解できない場合は、それらの関係を作成するためのより正規化された方法を探す必要があり、ツールを使用するだけでは得られないメリットがあります。通常、第 2 正規形と第 3正規形の間のどこかがスイートスポットです。ただし、高度な正規化が意味を持ち、価値を付加するリレーショナル データの小さな領域が常に存在する傾向があります。

乾杯、トラヴィス

于 2009-09-17T17:38:41.643 に答える