問題タブ [cross-join]

LINQ to SQL で CROSS JOIN を実行するにはどうすればよいですか?

CROSS JOIN2つのテーブルのMASSIVEを作成するプロセスを移植しています。結果のテーブルには15mのレコードが含まれます（プロセスが2600行のテーブルと12000行のテーブルと30mのクロス結合を行い、グループ化を行って半分に分割する必要があるようです）。行は比較的狭く、6列だけです。それは完了の兆候なしで5時間実行されています。既知のグッドとクロスジョインに期待するものとの間のカウントの不一致に気付いただけなので、出力にはファイナルテーブルを半分にするグループ化または重複排除がありません-しかし、これはまだ完了しないようですすぐに時間。

最初に、可能な限りこのテーブルをプロセスから削除することを検討します。明らかに、両方のテーブルを個別に結合することで置き換えることができますが、現在、使用されている他のすべての場所を把握することはできません。

しかし、既存のプロセスがそれを実行することを考えると（FOCUS言語を使用して、より短時間で、より強力でないマシンで）、CROSS JOINSQL Server（2005）の大容量のパフォーマンスを改善するためのオプションはありますか（ハードウェアは実際にはオプションではありません、このボックスは、32 GBのRAMを備えた64ビット8ウェイです）？

詳細：

これはFOCUSで次のように記述されています（同じ出力を生成しようとしています。これはSQLのCROSS JOINです）。

したがって、必要な出力は実際にはCROSS JOINです（両側から空白の列を結合しています）。

SQLの場合：

SQLコードの場合：

このテーブルがその後どのように使用されるかに応じて、作成に使用された元のテーブルの両方に結合するだけで、プロセスから除外できるはずです。CROSS JOINただし、これは非常に大きな移植作業であり、しばらくの間テーブルの使用法が見つからない可能性があるため、そのような大きなテーブルをタイムリーに作成するためのトリックがあるかどうか疑問に思いました（特に既存のプロセスを考えると） FOCUSではよりスピーディーにそれを行うことができます）。そうすれば、置換クエリの構築の正しさを検証し、後でビューなどでそれを除外することができます。

また、UDFと文字列操作を除外し、最初にCROSS JOINを実行して、プロセスを少し分割することも検討しています。

結果は非常に遠い：

UDFはパフォーマンスに大きく（マイナスに）貢献していることがわかります。しかし、15mの列の交差結合と30mの列の交差結合の間にも大きな違いがあるように見えます。私はSHOWPLANの権利（boo hoo）を持っていないので、インデックスを変更した後、使用しているプラ​​ンが良いか悪いかわかりません。まだリファクタリングはしていませんが、テーブル全体がまもなくなくなると予想しています。

私は3つのテーブルを持っています:

MyValue の行は、実際の値が提供された場合にのみ作成されます。

次のように、結果を表形式で表示したい：

クロス結合を正常に作成しました:

または、 linq で:

そして、linq でピボットを作成する方法を見ました ( hereまたはhere ) :

( MyDatas が前のクエリの結果を含むビューであると仮定します) :

しかし、可能であれば、Month1、... プロパティを動的に使用して結果セットを作成する方法を見つけたいと考えています。

注：n + 1クエリになるソリューション：

以下の 2 つの SQL は同じ結果を取得します。

さまざまな会社で両方のスタイルが標準として使用されているのを見てきました。私が見た限りでは、オンラインで最も多くの人が推奨しているのは 2 番目です。スタイル以外にこれの本当の理由はありますか？内部結合を使用するとパフォーマンスが向上する場合がありますか?

Ingres と Oracle の開発者は最初のスタイルを使用する傾向があり、Microsoft SQL Server のユーザーは 2 番目のスタイルを使用する傾向があることに気付きましたが、それは単なる偶然かもしれません。

洞察をありがとう、私はしばらくこれについて疑問に思っていました。

編集: 間違った用語を使用していたため、タイトルを「SQL 内部結合とデカルト積」から変更しました。これまでのすべての応答に感謝します。

無効な SQL を生成する Hibernate に問題があります。具体的には、暗黙的結合と明示的結合の混合と一致。これは未解決のバグのようです。

ただし、これが無効な SQL である理由がわかりません。同じ構文例外を生成する小さなおもちゃの例を考え出しました。

スキーマ

データ

ワーキングSQL

これらのクエリは両方とも機能します。デカルト積があることに気付きました。それは意図的なものです。

明示的な結合:

暗黙の結合:

無効な SQL

このクエリは、MSSQL 2000/2008 または MySQL では機能しません。

MS2000 では、次のエラーが表示されます。

列のプレフィックス 'e1' が、クエリで使用されているテーブル名またはエイリアス名と一致しません。

MySQL では、エラーは次のとおりです。

「on 句」の不明な列「e1.managerEmployeeID」。

質問

1. この構文が無効なのはなぜですか?
2. おまけ: Hibernate に明示的な JOIN のみを使用させる方法はありますか?

SQL Server 2005 で実行される、生成された SQL のパフォーマンスを判断しようとしています。

CROSS JOINS を使用しますが、クロス結合されたテーブルを結び付ける条件は where ステートメントにあります。

以前は、WHERE ステートメントを含むクロス結合はすべて、最初に完全なデカルト積を取得してからフィルターを適用すると考えていました。

ただし、MSDN の次のリンクでは、別の提案が示されています。

https://msdn.microsoft.com/en-us/library/ms190690.aspx

クロス結合されたテーブルに条件がある場合、内部結合のように「動作」することが具体的に述べられています。条件付きの内部結合とクロス結合の同様の結果の例を示します。

ただし、パフォーマンスの違いが何であるかは述べていませんが、同様の方法で動作することのみを示しています。

いくつかの情報源から経時的な温度サンプルの表を取得しており、設定された時間間隔ですべての情報源の最小、最大、および平均温度を見つけたいと考えています。一見すると、これは次のように簡単に実行できます。

ただし、問題の間隔中に欠落しているソースを無視するのではなく、欠落しているソースの最後の既知の温度を使用したい場合、ソースがドロップインおよびドロップアウトする場合、事態ははるかに複雑になります (私が困惑するところまで!)。サンプル。日時を使用し、時間の経過とともに不均一に分布するサンプル全体で間隔 (たとえば、1 分ごと) を構築すると、事態はさらに複雑になります。

最初のテーブルからの時間が2番目のテーブルの時間以上であるサンプルテーブルで自己結合を実行し、グループ化された行の集計値を計算することで、必要な結果を作成できるはずだと思いますソース。しかし、私は実際にこれを行う方法について困惑しています。

これが私のテストテーブルです：

最小値、最大値、平均値の計算を行うには、次のような中間テーブルが必要です。

次のクエリは、私が望むものに近づけていますが、指定された時間間隔での最新の結果ではなく、ソースの最初の結果の温度値を取ります:

更新: chadhoc (ちなみに、素晴らしい名前です!) は、彼が使用する をサポートしていないため、残念ながら MySQL では機能しない優れたソリューションを提供しFULL JOINます。幸いなことに、単純なUNIONものが効果的な代替品であると私は信じています。

更新 2: MySQL はEXPLAINchadhoc のコードに対して次の出力を提供します。

Charles のコードを次のように動作させることができました。

その説明は次のとおりです。

顧客とアイテムの2つのテーブルをクロス結合しようとしているので、アイテムごとのレポートで顧客ごとの売上を作成できます。私は2000の顧客と2000のアイテムを持っています。

SELECT customer_name FROM customers; --Takes 100ms

SELECT item_number FROM items; --Takes 50ms

SELECT customer_name, item_number FROM customers CROSS JOIN items; Takes 200000ms

これが400万行であることは知っていますが、これをさらに高速に実行することは可能ですか？最終的には、次のような販売テーブルに参加したいと思います。

SELECT customer_name, item_number, sales_total FROM customers CROSS JOIN items LEFT JOIN sales ON (customer.customer_name = sales.customer_name, item.item_number=sales.item_number);

販売テーブルには明らかにすべての顧客またはすべてのアイテムが含まれるわけではないため、ここでの目標は、すべての顧客とすべてのアイテムを、販売されたものと販売されなかったものとともに表示するレポートを作成することです。

PostgreSQL8.4を使用しています