はじめに
基幹系システムの開発に携わり、ビジネスロジックをT-SQLとPL/SQLで書いてきました。
ビジネスロジックをストアドプロシージャ上に実装することについて、思ったことを書いておきます。
利点
アプリケーション全体のアーキテクチャをシンプルにできる
ビジネスロジックとUIが物理的に分かれるので、フレームワークやデザインパターンに精通せずとも、レイヤー構造を作れます。
プログラマのスキルに差があっても品質に影響しにくい
良くも悪くもストアドプロシージャは自由度が低いです。誰が書いても同じコードになりやすいです。
分業がしやすい
ビジネスロジックとUIが完全に分かれているので、誰が何をするのかが明確になります。言語も違いますからね。
パフォーマンスが悪化しにくい
DB側で実行されるので、アプリサーバ－とDBサーバ間のラウンドトリップを気にする必要がありません。ORMのN+1問題などとも無縁です。
欠点
開発環境が貧弱
開発はDB管理用のソフト(SSMS, SQL Developerなど)で行うので、基本オマケ機能です。開発支援機能が少なく、コードの追跡やデバッグは大変です。
言語機能が貧弱
基本的に手続き型で、機能も少ないので長いコードになります。重複コードが発生しやすいです。
RDBMSを変更できない
ストアドプロシージャは製品固有の言語で記述されるため、ベンダロックイン状態になります。DBの変更が無い環境であれば特に問題にはなりませんが。
バージョン管理システムに乗せるのが難しい
DB上にプログラムが格納されるので、バージョン管理システムとは相性が悪いです。
自動ユニットテストの導入が困難
ビジネスロジックとDBが密結合していますので、xUnitのような仕組みの導入が難しいです。CI/CDは夢のまた夢かもしれません。
まとめ
ストアドプロシージャへの悪口を並べたような恰好になりましたが、組織によっては、ストアドプロシージャの方が向いている場合もある、ということが言いたかったです。
しかしながら、RDBMSとの結合度の高さは、様々なしがらみを生み出します。これをよしとするかの判断が必要になります。