SQLクエリをRスクリプトから分離するメリットと課題

SQLクエリの外部化管理、日本で本当に浸透する？現場あるあるハードル

SQLのクエリをRスクリプト内に書くか、それとも外部ファイルに分けるかって、うーん、昔から微妙に話題になるよね。ま、あれだ、自分の場合は何度かレポート更新しながら似たような修正やってて、「あれ？このSQLどこに書いたっけ」みたいになったのが発端だった気がする。実はそうでもなくて…いや、やっぱり面倒なんだよ、RMarkdownファイルぐるぐる探す作業。

まあいいか。でさ、もしSQLを外側のファイルとして保存しておいて、readr::read_fileとかで呼び出す運用なら、中身のコード全部追い回す必要もないわけで、小さい変更もgitとかで差分見やすい—らしい。実際自分も少し試したことある。ただ、この方法が絶対良いとは限らないし、人によって合う合わないあると感じたなあ。

編集が楽、とか再利用できる、とかメリット挙げる人いるけど、その割には「七十多」くらい年齢層高め？の人しか積極的じゃない印象も受けた。でもたしか複数レポートまたがって作業急ぐ場面では、別ファイル管理の緩さというか柔軟さが効いてきた事例も…ちょっとだけ聞いた覚えあるよ。

…あー、自分そこまで細かな運用法ちゃんと説明できるほど詳しくない部分あるんだけど、一度この手法試した人は意外にも元に戻れなくなるパターン、多いらしい。いや、本当なのかな。でも耳にはしたことある。

本段の参照元: https://www.johnmackintosh.net/blog/2022-02-08-separate-sql/

それでも諦めない！VSCodeで快適デバッグするための布教活動

SQLを外部ファイル化して管理する手法について考えていると、うーん、やっぱりRスクリプト内で直接クエリを書いちゃう場合と比べて、実運用ではだいぶ雰囲気が違ってくるよね。なんというか、readr::read_fileみたいな関数で.sqlファイルを読み込めば、RMarkdownやRのコードをあちこち探し回る必要がなくなるから、そのぶん「何がどこにあるのか」も把握しやすくなる――ま、それは一理あるかな。でも、そこで油断すると危険なんだよな。気づいたら命名規則も曖昧で、保存場所もバラバラになって、「あれ、このファイル同じ名前だけど中身違うじゃん」とか、「参照先間違えてエラー出た…」みたいな混乱が発生しやすい。えっと…ちょっと話それたか？戻すけど、とにかく正しい運用例としてはプロジェクト直下にsqlディレクトリを設置して、その中に用途ごとのサブフォルダと分かりやすい命名規則（たとえばreport_x_summary.sqlとか）を決めておくこと。これなら後で「あのSQLどこ？」って焦ることも少ない。逆に、不適切な例としては、一時的にデスクトップなどへ保存して、そのつど手動でパス指定する方法だけど――これ、本当に後々面倒というか、共同作業でもトラブルになりがちなんだよね。ま、いいか。そういうわけで整理整頓、大事ですよ、と言いたかっただけです。