誰も読めない2万行の
「秘伝のSQL」
「パフォーマンスのために」と、前任者は全てのロジックをPL/SQLで書きました。
そこはGitの管理外であり、デバッグもできず、コメントもありません。
それはもはやデータベースではなく、魔窟です。
- ビジネスロジックの変更があるたびに、DBAにお願いする必要がある
- バージョン管理システム（Git）には「DB更新用のSQLファイル」が1つあるだけだ
- アプリケーションコードはスカスカで、何をしているか読み取れない
- テストコードを書こうにも、DBがないと何も検証できない
クラウド移行やDBエンジンの変更は、事実上「不可能」です。
01. 継ぎ足しの秘伝タレ
DECLARE @Total DECIMAL(10,2)
-- 2015/04/01 Added by Tanaka
IF EXISTS (SELECT * FROM Users WHERE ...)
BEGIN
UPDATE Sales SET ...
-- 2016/10/20 Mod by Sato: Fix Bug #123
INNER JOIN (SELECT ... FROM ... WHERE ...)
-- 2018/01/01 New Year Campaign Logic
CASE WHEN Amount > 10000 THEN ...
-- What is this constant 0.08?
END
...(x 10000 lines)...
ストアドプロシージャは強力ですが、現代の開発フロー（CI/CD、ユニットテスト、コードレビュー）と非常に相性が悪いです。
ロジックがアプリケーションとDBに分散することで、システム全体の挙動を把握することが困難になります。
それは「老舗の秘伝のタレ」のように、誰も成分を知らず、捨てることもできないアンタッチャブルな存在になります。
DBにはデータだけを置け。
02. ベンダーロックインの罠
OracleのPL/SQLや、SQL ServerのT-SQLなど、独自の拡張構文に依存しすぎると、
PostgreSQLやMySQL、AuroraなどのクラウドネイティブなDBへの移行が極めて困難になります。
DBは「永続化層（Persistence Layer）」としてシンプルに保つのが、長生きするシステムの秘訣です。
03. どうしても使うなら
どうしてもパフォーマンス上の理由でストアドプロシージャが必要な場合は、
「APIとして扱う」という意識が必要です。
入力を受け取り、結果を返すだけの純粋な関数として設計し、ロジックの複雑さをカプセル化する。
そして、Gitで管理し、マイグレーションツールでデプロイを自動化することが最低条件です。