とりあえず実行計画見たらある程度はわかると思う SQLの場合は短いほうが効率良いという原則はなくて、営業から無茶なデータ要求されて仕方なく現実的なパフォーマンスが出せるように頑張ったらクソ長くなるのは普通にあるある

長いSQLは、サブクエリー、ユニオンなどで構成されていると思うので、分離できます。その為、必要があれば分解して個々確認します。 ジョイン・セレクト項目に関しては、関係ない所を削ったりしつつ簡素化して確認します。 慣れると長さは気にならなくなるかもですね。

SQLの長さに関係なく、デバッグすることは出来ません。各言語のテストの中でシナリオを作って確認するしかありません。 そもそも、長SQLになるのは、テーブル設計のせいがほとんどです。その原因は、テーブル設計者の思う美しさと、SQLの美しさは違うからです。

SQLにはデバック機能があるし、そもそもSQLはAPIと同じでDB管理者が用意するものですね。つまりプログラマにはDBを触らせない、余計なデーターは見せないが基本概念にありますから。

そのクソ長いSQL書く位なら、Perl辺りでバッチファイル書いてSQL叩くかも。 そうすれば複数個のSQLにわけて、プログラミングでフォローできる部分はプログラミングでやる。 まあそれができない場合もあるといえばあるので要求次第ではありますが。

私はこれが嫌だからSQLは使いたくない

qiita.com/toshihirock/it… ログとか見たことございませんか？ たまにSQL使えない人間が ログとして UIの画面キャプチャを 数千枚貼り付けてて 戦慄することの方が多いですよ 30件までしかログは表示できない仕様です とか書いてたり 本当GUIはクソです…

勘

SQLを、ブラックボックスとして、「ブラックボックステスト」をします。 入力に対して、出力が意図したとおりであるか、各パターンの真理値表などを作って、バリエーションテストします。 あと、異常系、大量系、負荷テストですね。 これが通ったら、中身を熟知してなくても大体問題ないです。

あらゆるデータパターンを定義して正しく抜けるかチェックするんだよなぁ。あり得ないほど時間かかるけど、それが品質の証らしい。