ストアドプロシージャに以下があります
if
then
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE2 where criteria1 (covers functionality 1)
UNION
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE3 where criteria2 (covers functionality 2)
UNION
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE4 where criteria3 (covers functionality 3)
elseif
then
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE5 where criteria4 (covers functionality 4)
UNION
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE6 where criteria5 (covers functionality 5)
UNION
SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE7 where criteria6 (covers functionality 6)
これらのSQLを個別に(並列に)実行してから、結果をセットに入れる(一意のみを取得する)のは良い考えですか?
理論的には理解したいのですが、今は見えないものがありますか?
SQLは別個のDB2ストアード・プロシージャーであるため、内部でそれらをすでに並行して実行している可能性があります。
アプリケーションからクエリを並行して実行し、出力を結合することは、データベースから調整されたクエリを実行するほど速くはありません。
データベースエンジンは、データセットを操作するように設計および最適化されています。確かに、一部のデータベースエンジンは他のエンジンよりも効率的ですが、これが主要なタスクです。外部キー参照を使用するだけで、データベースは2つのテーブルを接続する(それらを結合する)パフォーマンスを何桁も向上させることができます。
クライアントよりもデータベースよりも高速に実行できるものを表示できる場合でも、データをネットワークパイプに移動するのにかかる時間を考慮する必要があります。必要な1または2にフィルターするためだけに、100Kレコードをクライアントに移動するのは簡単です。
ネットワークを介して大量のデータセットを送信すると、ネットワークを使用する他のアプリケーションのパフォーマンスにも悪影響を及ぼします。
すべてのデータが同じテーブルから取得されるため、これはユニオンの奇妙な使用法です。
代わりに、より複雑なwhereステートメントを使用して単一の選択を行うことができます。
今!一方が他方よりもパフォーマンスが高いかどうかは、where句に依存すると思います。
それらをparralellで実行する意味がわかりませんか?コードから呼び出し、結果を反復しますか?データベースとは異なるサーバーでコードを実行している場合、これはよりスケーラブルになります
パフォーマンスに関しては、並列実行が向上しますが、コードに関しては、ストアドプロシージャ内のすべてをユニオンに配置する方がよい場合があります。
将来、変更が必要な場合(たとえば、他のテーブルを結合することによってフェッチされたデータの更新)、またはクエリに追加された他の3〜4個のユニオンを言う場合。次に、ストアドプロシージャ/クエリを頻繁に呼び出すコードをリファクタリングする必要があります。
単一のSELECT
を使用して、より複雑なWHERE
句を使用する方が、設計の点でより良い代替案であると思います。
また、データベースが重複を排除する必要があるため、偶然にもUNION
アプローチが遅くなることも予想されます。代わりにUNION ALL
を使用している場合、どの代替案の方がパフォーマンスが優れているかを推測することはできません(測定する必要があります)。