2

Javaで構造化された方法でクエリを自動的に生成するために使用されるコードを自動生成するプログラムを開発しました。

私が追加した最新のオプションは、実際には他のテーブルの制約を指定しながら、1 つのテーブルの結果を取得することです。唯一の前提条件は、これらのテーブルが相互に外部キーを持つことです。

ここでは、実際の SQL クエリのみを扱います。

これは、よく使用される有効な SQL クエリです。

SELECT businessPartners.businessPartnerId, businessPartners.name
FROM businessPartners
JOIN BP_emails ON businessPartners.businessPartnerId = BP_emails.businessPartnerId
JOIN emails ON BP_emails.emailId = emails.emailId
WHERE emails.email = "test@test.com"

電子メール アドレスに基づいてビジネス パートナーを選択します。businessPartners.businessPartnerIdemails.emailIdは両方とも主キーでBP_emailsあり、その中に外部キーがあります。

同様の構造が、請求書と請求書と電子メールの間のリンクにも使用されています。

したがって、このクエリを実行できることもわかりました(および確認しました):

SELECT businessPartners.businessPartnerId, businessPartners.name
FROM businessPartners
JOIN BP_emails ON businessPartners.businessPartnerId = BP_emails.businessPartnerId
JOIN emails ON BP_emails.emailId = emails.emailId
JOIN INV_emails ON emails.emailId = INV_emails.emailId
JOIN invoices ON INV_emails.invoiceId = invoices.invoiceId
WHERE invoices.invoiceId >=1
AND invoices.invoiceId <=1

まず第一に、それが正確に何を意味するのかを理解するのに苦労しています.次のような意味だと思います.invoices.invoiceId = 1請求書に関連する電子メールがビジネスパートナーに関連する電子メールと同じであるすべてのビジネスパートナーを教えてください..あまり意味がないと思います。

問題は、複数の結合が実際に意味をなすのはどこまでかということです。最初の例ではすでに 2 つの結合が必要でしたが、3 つ以上の結合が必要な正当な例はありますか?

これで何か助けていただければ幸いです。

4

3 に答える 3

1

私が聞いた経験則では、JOIN 内の 7 つを超えるテーブルは多すぎるということです。

ここで重要なのは、JOIN の数ではなく、WHERE 句の適切な順序です。SQL はセットベースであるため、最初に最大行数を除外する WHERE 句を実行すると、後続のフィルターの作業を節約できます。

インデックス作成もパフォーマンスに影響します。WHERE 句のすべての列にインデックスがあることを確認してください。

言うまでもなく、すべてのテーブルには主キーが必要であり、それに対して JOIN を実行する必要があります。

申し訳ありませんが、これはばかげています:

WHERE invoices.invoiceId >=1
AND invoices.invoiceId <=1

これが自動生成されるものの例である場合、より良いジェネレーターが必要だと思います。

于 2013-07-10T20:23:31.893 に答える
1

クエリは問題ないようです。パフォーマンスに問題なく、最大 10 個の結合がありました。

MySQL のパフォーマンスに関する興味深い事実:

  1. 常に MySQL を使用してquotesください。私は厄介なクエリのパフォーマンスを改善する任務を負っていました。私が最初にしたことは、コードを読みやすい方法で配置し、引用符を追加することでした. その結果、パフォーマンスが 10% 上昇しました。

  2. 常にインデックス付きの数値フィールドで結合し、他のオプションが存在しない場合を除き、結合で 2 つの条件を使用しないでください。パフォーマンスが低下する原因となります。

  3. 条件が常に最初にインデックスを持つ最小量を選択する順序でそれらを追加する場合、これによりパフォーマンスが最大 99% 向上します。

ちょうど私の2セント。

于 2013-07-10T20:59:18.177 に答える
0

本当に言うのは難しいですが、確かにやや扱いにくいですが、例があまりにも多くの問題であるとは思えません。あなたがしていることを考えると、長いSQLはそれほど問題ではありません。うまくいけばもっと表現力のあるプレゼンテーションの背後に隠れているからです。あなたが表現できる関係の数の任意の制限に相当するものを入れるのをためらっています. 遅いことが判明した場合、それはスキーマの変更であり、私が見る限り、範囲外です。

于 2013-07-10T20:57:13.167 に答える