SQLはシンプルであるべきだ

前語り

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

システム開発・運用とSQLは切り離すことは不可能です。それほど便利で浸透した技術であると言えます。様々な使用方法があります。

しかし、SQLはシンプルであるほうが良いと考えます。

SELECT,INSERT,UPDATE,DELETEとWHERE,ORDER BYくらいで事足りるので、それ以外は無くなってもよいと思っています。

SQLのここがダメ ビルド編

SQLをコンパイルした後に使う方法も存在しますが、文字列で定義してSQLを使用しているもプロジェクトも多いと思います。この場合何が起きるか？

カンマや括弧の数が足りない、カラム名が間違っているなどSQLでもビルドを通ってしまい、実行するまでミスに気付けないのです。現代とは思えません。

SQLのここがダメ デバッグ編

上述のように文字列で定義したSQLをデバッグする際、SQLの前後にブレークポイントを貼ってSQLの結果を待つことになり、SQLの途中で止めることはできないはずです。

エラーや想定していない結果が返ってきた場合、SQLを手探りで修正していくことになります。とてもしんどい作業になります。

SELECT * FROM table WHERE 条件 で済むのならそんなことにはならないのに。

SQLのここがダメ 速度編

自分が昔携わったプロジェクトで以下のような1つのSQLがありました。

4つのテーブルに対してWHEREやJOIN、ORDER BY、CONTAINS、比較演算子などを駆使しまくったそれは大層なSELECT文でした。

このSQLは、実行してから結果が返ってくるまでに2分以上かかるというひどいものでした。

各テーブルに対して、シンプルな4つのSELECT文で4つのテーブルの情報を取得し、ソース上でfor文やif文を使って処理を行うように変更したところ、1秒もかからずに処理できるようになったということがありました。なんて愚かなのでしょう。

SQLのここがダメ 可読性編

上述のケースで、ソースに書き起こすと、5重ループのような処理になっていました。

ソースで書いていたら、なんとかして改善点はないか探すことになるでしょう。

ただ、SQLで書いてしまうと改善点に気付けず、問題のある処理がそのままになってしまうことが多々あります。それだけSQLは読みづらいものなのです。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞