【SQL】統一ルールを作ろう！おすすめSQL記述ルールを解説！

このコラムでは、データマーケティングにまつわる様々な情報をお届けします。

今回のテーマは「SQL記述ルール」です。

「人が書いたSQL読みにくいなー」と思ったことはないでしょうか？

データマーケティングの現場では、エンジニアではなくてもSQLに触れる機会は多いと思いますが、そんなSQLを仕事で使っている方にとって、あまり他の人のSQLの読解に時間を使うのは大変だと思います。

「大文字・小文字が乱立している・・」「変なとこで改行している・・」「結合条件などの意図を汲み取りづらい・・」など、自由に記述されたSQLは読みにくく、生産性を落とす原因にもなります。

そういった問題が起きないようにするためには、チームでSQL記述のルールを作る必要があります。この記事では、「Legolissではどういうルールで運用しているか」を中心にご紹介したいと思います。

・SQLの記述を揃えることのメリット
・弊社ルール
・まとめ
※今回対象のシステムはTreasureDataのPrestoです。

メリットとしては、
「SQLが見やすくなる（どういう内容が記述されているか分かりやすい）」
→「保守性が高くなる（他の人が記述した内容が読みやすい、Wチェックや仕様変更に対応しやすい）」
が挙げられます。

例えばですが、以下のようなSQLは実行はできますが、非常に見づらいです。

その原因は【「SQLにとって必要なもの」と「運用者にとって必要なもの」が切り分けられていない】ためです。色分けは行われていますが、視覚的な差別化が弱く、一覧性も担保できていません。
そこでSQLのインデントやスペースを整えてみます。

SQLに必要なものと運用者が入力・指定したものの違いや、一覧性の向上、意図していることがブロックで表現されていることによる視認性の高さが生まれているのがわかるでしょうか。

個人でSQLをアドホック（1回限り）で使う場合は、そこまで考える必要はないかもしれませんが、仕事上チームで使う場合はSQLを読むのに必要な労力と時間を意識して、誰もが読みやすいルールを作り、全員がそのルールを守ることで、より効率的に業務を進めることができます。

どれが正解という訳でもなく、流派が多くあるかと思いますが、以下弊社でのルールをご紹介したいと思います。

①大文字小文字を使い分ける

・大文字：SELECT、FROM、WHERE、JOIN、AS、AND、OR、その他関数
・小文字：テーブル名、カラム名

大文字・小文字のルールを作るだけでも可読性が変わってきます。
ルールとしては、予約語（SQLのルールで指定された言語）や関数は大文字に、非予約語（テーブル名やカラム名などデータベース毎に独自に意味をもつもの）は小文字にするというルールを採用しています。

②インデントを合わせる

・1カラム1行
・インデントは半角スペース2つ（＝ TreasureDataやBigQueryでの「Tab」一つ分）
・カンマは行頭・WHERE句の中のAND/ORの前で改行（AND/ORを先頭に）
・「＝」「>」などの不等号の前後は半角スペース1つ

横に長く記述すると可読性が良くないので、どんどん縦に記述していくイメージです。
不要になった行をすぐに特定できたり、コメントアウトでカラムの説明を記載することもやりやすくなります。

③関数、結合条件のパターンを作る

●WITH、CASE、JOINなど良く使うものはパターンを作る。
・WITH：()や改行の位置をを揃える。
・CASE：WHENとELSEの前で改行する。
・JOIN：ASでテーブル指定、結合条件は1行に収める。

このルールの根底も②と同じで、どんどん縦に記述していくイメージです。
SQLは常に修正されていくことを意識して、いかに修正しやすいかを元に各ルールを採用しています。

＜例＞
以下のSQLがそれぞれの要点を押さえたものです。

ルールを作らなくてもSQLは実行できますが、チームで運用する場合はお互いの意識を合わせることで認識の違いや確認のコストを減らすことが可能です。弊社のルールをベースに一度チームで話し合い、チームに最適な形を検討してみてはいかがでしょうか？

ナレッジ&コラムKnowledge & Column