【アーキテクチャ】なぜ「ビジネスロジック」はDB（ストアド）からバックエンドへ移動したのか？徹底解説

最近、現場でこんな話を聞いたことはありませんか？
「データ加工などのロジックは、DB（ストアドプロシージャ）ではなく、バックエンド（アプリ側）に書こう」

昔ながらのシステム開発では、DBの**ストアドプロシージャ（Stored Procedure）**にガッツリ処理を書くのが主流でした。しかし、現代のWeb開発（クラウド時代）では、役割分担が大きく変わっています。

今回は、なぜこの「パラダイムシフト」が起きたのか？
**「スケーラビリティ」「開発効率」「ベンダーロックイン」**の3つの観点から、その理由を初心者にも分かりやすく解説します。

1. 📈 スケーラビリティ（拡張性）の問題

これが最大の理由です。
一言で言うと、**「クラウド時代になり、サーバーの増やし方のルールが変わったから」**です。

この違いは、よく**「社長と平社員」**に例えられます。

「貴重で高価な社長（DB）を疲れさせるな。計算などの雑務は、安くて無尽蔵に増やせる平社員（Webサーバー）にやらせろ」

重い計算処理をDBでやってしまうと、アクセス集中時に「社長」が倒れ、サービス全体が停止してしまいます。だから、ロジックはアプリ側に逃がすのです。

プログラマーの日々の「働きやすさ（Developer Experience）」において、アプリ側での実装は圧倒的に有利です。

アプリ側 (Python/Java/Go):
ソースコードはテキストファイルです。GitHubなどで「誰が・いつ・どこを修正したか」を1行単位で完璧に管理できます。レビューもしやすいです。
DB側 (ストアド):
プロシージャはDBの中に保存される「定義」です。Git管理しようとすると、DDL文を抽出して管理する必要がありますが、アプリコードほど直感的ではありません。「本番環境で直接修正してしまい、Gitと整合性が取れなくなる（先祖返り）」事故も起きがちです。

アプリ側:
JUnit や PyTest などで、ボタン一つで自動テストが走ります。エディタのデバッガを使えば、1行ずつ処理を止めて変の中身を見ることも簡単です。
DB側:
ストアドのテスト自動化は準備（データのセットアップ）が大変です。デバッグも PRINT デバッグが主流になりがちで、**「暗闇を手探りで歩く」**ような難しさがあります。

これはビジネス的・戦略的な理由です。

プロシージャを書く言語は、DB製品ごとに全く異なります。

もし、ビジネスロジックを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（データの重力）」**と言います。
「データは重くて動かすのが大変。だから、軽いロジックの方をデータがある場所に持っていけ」という考え方です。

現代のWeb開発における、データ加工の役割分担は以下の通りです。

「なんでもかんでもDBでやる」時代から、「適材適所」の時代へ。
この原則を知っていると、設計のレベルが一段上がります！