【アーキテクチャ】なぜ「ビジネスロジック」はDB（ストアド）からバックエンドへ移動したのか？徹底解説
最近、現場でこんな話を聞いたことはありませんか？
「データ加工などのロジックは、DB（ストアドプロシージャ）ではなく、バックエンド（アプリ側）に書こう」
昔ながらのシステム開発では、DBの**ストアドプロシージャ（Stored Procedure）**にガッツリ処理を書くのが主流でした。しかし、現代のWeb開発（クラウド時代）では、役割分担が大きく変わっています。
今回は、なぜこの「パラダイムシフト」が起きたのか？
**「スケーラビリティ」「開発効率」「ベンダーロックイン」**の3つの観点から、その理由を初心者にも分かりやすく解説します。
1. 📈 スケーラビリティ（拡張性）の問題
これが最大の理由です。
一言で言うと、**「クラウド時代になり、サーバーの増やし方のルールが変わったから」**です。
サーバーを増やす戦略の違い
- DBサーバー（プロシージャ）: スケールアップ（性能強化）が基本
- Web/アプリサーバー: スケールアウト（台数増）が基本
🏢 社長と平社員の法則
この違いは、よく**「社長と平社員」**に例えられます。
-
**DBサーバーは「社長」**です。
-
会社に1人（または少数）しかいない、替えの効かない存在です。
-
「もっと働いて！」と言っても、社長の体（CPU/メモリ）には限界があります。
-
社長を増やしたり、もっと優秀な社長（高性能サーバー）に交代させるのは、めちゃくちゃ大変でお金もかかります。
-
**Webサーバーは「平社員」**です。
-
仕事が増えたら、求人を出して（クラウド設定を変えて）10人、100人と簡単に増やせます（オートスケーリング）。
-
1人が倒れても、他の社員が代わりを務められます（ステートレス）。
現代の鉄則
「貴重で高価な社長（DB）を疲れさせるな。計算などの雑務は、安くて無尽蔵に増やせる平社員（Webサーバー）にやらせろ」
重い計算処理をDBでやってしまうと、アクセス集中時に「社長」が倒れ、サービス全体が停止してしまいます。だから、ロジックはアプリ側に逃がすのです。
2. 🛠 開発効率と管理（Git・テスト）の問題
プログラマーの日々の「働きやすさ（Developer Experience）」において、アプリ側での実装は圧倒的に有利です。
🔄 バージョン管理 (Git)
-
アプリ側 (Python/Java/Go):
ソースコードはテキストファイルです。GitHubなどで「誰が・いつ・どこを修正したか」を1行単位で完璧に管理できます。レビューもしやすいです。 -
DB側 (ストアド):
プロシージャはDBの中に保存される「定義」です。Git管理しようとすると、DDL文を抽出して管理する必要がありますが、アプリコードほど直感的ではありません。「本番環境で直接修正してしまい、Gitと整合性が取れなくなる（先祖返り）」事故も起きがちです。
🧪 テストとデバッグ
-
アプリ側:
JUnitやPyTestなどで、ボタン一つで自動テストが走ります。エディタのデバッガを使えば、1行ずつ処理を止めて変の中身を見ることも簡単です。 -
DB側:
ストアドのテスト自動化は準備（データのセットアップ）が大変です。デバッグもPRINTデバッグが主流になりがちで、**「暗闇を手探りで歩く」**ような難しさがあります。
3. 🔐 ベンダーロックイン（束縛）を避ける
これはビジネス的・戦略的な理由です。
「方言」がきついSQL
プロシージャを書く言語は、DB製品ごとに全く異なります。
- Oracle: PL/SQL
- PostgreSQL: PL/pgSQL
- SQL Server: T-SQL
もし、ビジネスロジックをPL/SQLでガチガチに書いてしまうと、将来「コスト削減のためにOracleからPostgreSQL（AlloyDBなど）へ移行したい」となった時、プログラムの全書き直しが発生します。
これを**「ベンダーロックイン」**と言い、身動きが取れなくなってしまいます。
アプリ側なら自由
PythonやJavaでロジックを書いておけば、接続先のDBが変わっても、ORMの設定や一部のSQLを変えるだけで済みます。**「DBはただのデータ保存場所」**として扱うことで、将来の選択肢を確保できるのです。
🤔 それでも「プロシージャ」を使う場面はある？
ここまで「プロシージャは使うな」という流れでしたが、ではプロシージャは**オワコン（死語）**なのでしょうか？
いいえ、そんなことはありません。
優秀なアーキテクトほど、「あえて」使う場面を知っています。
🚀 唯一にして最大の出番：大量データのバッチ更新
例えば、**「100万人のユーザー全員のポイントを一斉に計算して更新する」**ような夜間バッチ処理です。
| 処理場所 | 動き | 結果 |
|---|---|---|
| アプリ側 | 1. データを100万回取ってくる (SELECT) |
2. 計算する
3. 100万回書き込む (UPDATE) | 遅い
DBとWebサーバー間の通信（往復）がボトルネックになり、終わらない。 |
| DB側 | 1. データがある場所で計算・更新完結 | 爆速
通信が発生しないため、圧倒的に速い。 |
Data Gravity（データの重力）
これを**「Data Gravity（データの重力）」**と言います。
「データは重くて動かすのが大変。だから、軽いロジックの方をデータがある場所に持っていけ」という考え方です。
🎁 まとめ
現代のWeb開発における、データ加工の役割分担は以下の通りです。
- 基本戦略: ロジックは**バックエンド（アプリ側）**に書く。
- 理由：サーバーを増やしやすい（スケールアウト）、Git管理・テストがしやすい、DB製品に縛られない。
- 例外: 超大量データのバッチ処理などはプロシージャを使う。
- 理由：通信オーバーヘッドをなくし、パフォーマンスを最大化するため（Data Gravity）。
「なんでもかんでもDBでやる」時代から、「適材適所」の時代へ。
この原則を知っていると、設計のレベルが一段上がります！