章: 第5章: 設計品質を上げる
同じSQLをアプリの複数箇所にコピーしていませんか？
「論理削除を除いた有効ユーザーを取得するSQL」や「集計結果を求めるSQL」が、コントローラー・バッチ・APIエンドポイントにそれぞれコピーされている状態は管理が困難です。1箇所の条件変更が漏れると、データの不整合を引き起こします。
ビューとストアドプロシージャを使うと、共通SQLをDB側に1箇所集約でき、アプリコードをシンプルに保てます。 ただし、万能ではないため使いどころを正しく判断することが重要です。
ビューとストアドプロシージャの使い分け
| 機能 | ビュー（VIEW） | ストアドプロシージャ（Stored Procedure） |
| 主な用途 | 参照クエリの再利用・カラムの隠蔽 | 複数SQLをまとめた手続きの再利用 |
| 引数の受け渡し | 不可 | 可能 |
| トランザクション制御 | 不可 | 可能 |
| デバッグのしやすさ | 容易 | やや難しい |
| 向いているケース | 読み取り専用の集約・フィルタリング | バッチ処理・複数テーブル更新のまとめ |
| 注意点 | 複雑なビューはパフォーマンスが低下しやすい | ロジックがDB側に分散してバージョン管理が難しくなる |
チェックポイント: ストアドプロシージャはビジネスロジックをDBに持ち込みすぎると、アプリとDBの責務が混在してメンテナンスが困難になります。まずはビューから導入し、手続き的な処理が必要になった場合にのみストアドプロシージャを検討してください。
実際のコードサンプル
CREATE VIEW v_active_users AS
SELECT id, name, email
FROM users
WHERE deleted_at IS NULL;
SELECT * FROM v_active_users LIMIT 10;
まとめ & 次のステップ
- まずは読み取り専用のビューから導入し、共通SQLを1箇所に集約する
- ビューは
deleted_at IS NULLのような共通フィルターを隠蔽するのに特に有効 - ストアドプロシージャは複数SQL・トランザクション制御が必要な場面に限定して使う
- ビューのSQLが複雑になりすぎた場合は、アプリ側のRepository層に戻すことも選択肢に入れる
- どちらも変更時はアプリへの影響範囲を確認してからDDLを実行する
次回は 権限管理の基本（GRANT） を学びます。最小権限の原則でDBユーザーを設計し、セキュリティを強化する方法を解説します。
