現在かなり複雑なレポーティングクエリを構築しています。
一貫性のない形式で保存されているデータをSQLできれいに整形して出力するレポートなのですが、データ形式のパターンが10種類ぐらいあるんです。
最初にパターン1向けのクエリを作って、それからパターン2用に拡張して、次にパターン3を・・・と作っていったらパターン4のあたりで挫折しました orz
メインテーブルを利用するロジックは共通なので、SQL一発で取るようにした方がスマートかなと思ったんですが、だんだんとCASE式とOUTER JOINの乱れ撃ちになってきました。
なぜここでCASE式やOUTER JOINを使ったのか、という意図が自分で分からなくなってきてしまい、このままじゃパターン10までとても到達できなさそうに思えてきました。
CASE式が3つか4つネストした日には自分でも泣きそうになります。
そこで一発SQLをあきらめて、UNIONでSQLを一から書き直す事にしました。
イメージ的にはこんな感じです。
パターン1用のSELECT文
UNION ALL
パターン2用のSELECT文
UNION ALL
パターン3用のSELECT文
UNION ALL
パターン4用のSELECT文
…
こちらの方が書き手の意図が伝わりやすいですし、CASE式やOUTER JOINもほとんど出てこなくなります。
その反面、各SELECT文でコードが若干重複してしまいます。
共通する部分に変更が入ると10カ所をモレなく修正する必要があります。
また、カラムを追加したり削除したりするときもすべてのSELECT文に手を加えないといけません。
SQLも縦に長くなるので、始めて見た人は全体像をつかむのに苦労するかもしれません。
こういうデメリットがあるのでできればUNIONは使いたくなかったのですが、今回に限っては一発SQLよりもUNIONを使った方が得策だと判断しました。
