Union all は非効率的です。問題を解決するには、ストアド プロシージャ、ビュー、または一時テーブルのどれを使用する必要がありますか?
- WBOYオリジナル
- 2016-06-23 14:04:591383ブラウズ
Union all は非効率的です。union all にはおそらく数十のテーブルがあり、単一のテーブルの選択には 0.0003 ～ 0.002 秒しかかかりませんが、効率を向上させたい場合は、約 0.6 秒かかります。ストアド プロシージャ、ビュー、および一時を使用する必要があります。この問題を解決するにはどの方法を使用できますか?
ディスカッション (解決策) への返信
データが適切に整理されていないことは明らかです
このようなことが起こったことはありませんか?
組織 合理的であれば、そのような事態は起こりません
似たようなデータを数十のテーブルに垂直に分散させれば無理です
似たようなデータを数十のテーブルに垂直に分散させれば、合理的ではない 合理的
誰か良いアイデアはありますか？以前に作成したテーブルはいくつかの機能に適用されています。今すぐ変更するには大きすぎるプロジェクトです。
テーブルの構造を教えていただけますか?
同じではないのに、重ね合わせることに何の意味があるのでしょうか？
テーブルの構造を教えていただけますか?
同じではないのに、重ね合わせることに何の意味があるのでしょうか？今確認したところ、テーブルは7つあり、
1. 売上伝票、赤字の売上伝票
3. 領収書、支払伝票、振込伝票 の7つです。
このうち、グループ 1 とグループ 2 の構造は同じであり、グループ 1 とグループ 2 で異なるフィールドは 1 つだけです。
3 つのグループの回収伝票と支払伝票にも、転送伝票の構造が 1 つだけ異なります。
なお、グループ 1 とグループ 2 の内部テーブル構造は同じです。グループ 1 とグループ 2 で異なるフィールドは 1 つだけです。
グループ 1 とグループ 2 の異なるフィールドは次のとおりです。
グループ 1 には「販売注文番号、顧客コード」があります。
グループ 1 とグループ 2 のテーブル構造は次のようになります。これらを 1 つのテーブルにマージできますか?
データ量はどれくらいですか?サブテーブルの状況に到達する時が来ました。テーブルを分割する場合、このレベルの分割は合理的ではありません。
Union を使用するのは正しいです!
これらの 7 つのテーブルは並列です。接続したくても、結合することしかできません。
実際、それらはすべて異なることを説明しています。そのため、テーブルに分かれています。
1. 販売伝票、赤字の売上伝票
3. 受取伝票、支払伝票、振込伝票。
Unionを使えばいいんじゃないでしょうか？
これら 7 つのテーブルは並列です。結合したくても、結合することしかできません。
必要ないですよね？一部の機能に適用されていると言ってませんでしたか？
必要ないですよね？一部の機能に適用されていると言ってませんでしたか？
は、追加、削除、確認、変更を行う独自の機能です。この設計により、将来的に対処が難しい他の問題が発生するかどうかはわかりません。
もしよろしければ、ビジネス プロセスを説明してください
例えば、仕訳機能があります。この機能は、先ほどの7つのテーブルのレコードから、「銀行預金と現金」の2つの口座の詳細なレコードを検索するものです。これら 2 つの預金の詳細を抽出し、概要で表示する必要があります。
3 番目はアカウント概要テーブルです。これは、特定の期間内のアカウントごとのすべてのバウチャーの概要です。
4 番目の総勘定元帳には、各口座の詳細な記録がすべて表示されます。
あまり良い説明ではないかもしれません。すみません。
すべて結合した後に注文しましたか? そうでなければ、それほど大きな違いはないはずです