仕事の愚痴 Advent Calendar 7日目

7日目です。

仕事の愚痴

デカいSQLはやめよう、って話。
プログラム中にDBからデータを引っ張ってくるときにSQLを書くことが多い。通常、うちは設計書をそこまで細かく書くということがないが、たまに詳細設計でSQLの条件を細かく指定してくれているありがたいプロジェクトに出合ったりする。
しかし、その詳細な条件をしてしてあっても、困ったことがある。やるべきことが複数なのにそれを1本のSQLでやってしまうのだ。

その弊害

テストの難易度が上がる。「こっちとそっちの条件は変えないままあっちの条件を変えて実行」なんてことになって、脳内メモリをガンガン消費する。かなり集中しないと条件を追えなくなり、疲れる。そもそも、テストしたくなくなる。

どうしたらいいか?

可能であれば処理を分ける。
例えば、「Aという人を(上司に持つ人と承認者として持つ人)の数」をSQLで取得し、その件数が1件以上ならCという処理をする。
この場合、テストは、上司に持つ人だが承認者としては持たない人、上司には持たないが承認者として持つ人が取得できるかテストしなきゃいけない。条件が複合的で厄介。

これを、たぶん以下のように分けられる。

1.「Aという人を上司に持つ人の数」を求める
2.「Aという人を承認者として持つ人の数」を求める
3.1+2>=1ならCをする

こう分けると、SQLのテストは、1をテストし、2をテストすればよい。

例として挙げてるだけなので、正確じゃないかもしれないですが…。

まとめ

複数のことをやる大きなSQLは、分割したほうがテストしやすくなります。もちろん、大量処理の場合はSQLを分けると処理が遅くなります。しかし画面等では、多少遅くなってもテスト・メンテしやすい作りにしたほうが、バグが生まれにくいと思う。