もうStored Proceduresはやめよう、アプリ開発者からの懇願
We need to stop using Stored Procedures
アプリケーションからStored Proceduresを呼び出すのをやめるべきだと著者は主張する。パラメータ化クエリとプランキャッシュの利点は通常のクエリでも得られ、むしろアプリとDBアクセスロジックを同じバージョンで管理できる。ネットワークリクエスト、インデックス、ORM、デカルト積爆発など、アプリ開発者が知るべきDB操作の基本も解説する。
アプリケーション開発者よ、頼むから、Stored Proceduresへの依存をコードベースに入れるのはやめてくれ。
HNでの議論
22- saxenaabhi
これは非常にお粗末に書かれていて、基本的な事実で間違っている。
> では、ストアドプロシージャで何が得られるのか？
> 何も得られない！いや、つまり、頭痛の種が一つ、かな。
> ... クエリを更新するためにマイグレーションをデプロイしなければならないし、diff migration_for_my_sproc migration_for_my_sproc_n を実行して何が変わったか確認しなければならない
1) SQL関数はコードと一緒にリポジトリでバージョン管理でき、DBマイグレーションと一緒に（同じトランザクションでさえも）デプロイできる。
SQL関数ごとに1ファイルにしておけば、私のように600個のストアドプロシージャがあるリポジトリでも、チェックサムを計算して高速化できる。
2) ストアドプロシージャを使えば、複数のステートメントを実行するときにサーバー側で db.startTransaction を呼び出してDBのラウンドトリップを待つ必要がない。これがストアドプロシージャを好む最大の理由であることが多い。
3) 医療や金融のシステムで、異なるチームが基盤となるテーブルにアクセスできず、DBはSQLプロシージャだけを公開しているのを見たことがある。プロシージャが呼び出されるたびに、監査テーブルにログエントリも追加される。
データベースは素晴らしい技術だ！適切に使う方法を学べば、ビジネス価値の創出という点で大きな見返りが得られる。
追記：この記事では触れられていないが、人はよくストアドプロシージャのテストの難しさを口にする。
通常の vitest テストで、インメモリの pglite を使って postgres 関数をテストできる。
- JeffRosenberg
> アプリケーションコードとDBアクセスは別々にバージョン管理されていて、うちのsprocは異常な（つまり極めて稀で常軌を逸した）DBAによって足元で勝手に変わりうる
あなたのデータベース（とそのマイグレーション）は、残りのコードと一緒にソース管理されるべきだ。これで問題解決、あとはストアドプロシージャが持つ正当な利点のいくつかを活用すればいい！
- noddingham
（私たちのオンプレミスのSQL Server環境では）Web開発者に対して、ストアドプロシージャをAPIコントラクトのように公開して、データベースとのやり取りの整合性と堅牢性をある程度確保している。最近のWeb開発者のSQL知識は当てにならないことが多く、スキーマを設計してストアドプロシージャを提供するのはDBAに任せたい。