https://xtech.nikkei.com/it/article/COLUMN/20071126/287920/

ビュー，トリガーを多用してはいけない

開発フェーズで，データベース設計とアプリケーション設計との間で仕様の認識が異なっていることがよくある。そのようなとき，データベースもしくはアプリケーションのどちらかで仕様変更を吸収する必要に迫られ，ビューやトリガーといったデータベースとアプリケーションの中間に位置するグレーな部分で回避する場面をよく見かける。

　これは，構築したデータベースへの変更とアプリケーションへの変更を最小限に抑えるテクニックの一つである。しかし，このグレーな部分での回避策を多用すると，今後のデータベース，アプリケーション双方のメンテナンス性に対して大きな禍根を残すことが多い
カラムを一つ削除するのも大変
　確かに，ビューやトリガーは，使い方によってはアプリケーションで考慮しなくてはならないことをデータベース側で吸収できる優れた機能である。しかし，データベースから見ればビューやトリガーは通常のオブジェクトとは異なる特殊なオブジェクトと見ることができる。

　通常のオブジェクトは，（参照整合性制約などはあるが）単独で機能する。しかしビューやトリガーは単独では機能し得ない。複数のオブジェクトに依存して機能するオブジェクトである。この依存関係を正確に理解しておかないと，後の仕様変更やチューニングで面倒なことになる。

　きちんとした設計もなく小手先のテクニックとしてビューやトリガーを放置しておくと，ビューに対するビューや，そのビューに掛けられたトリガーなど深いネストを持つオブジェクトが生まれてしまう。

　このような場合，あるテーブルのカラムを削除したい要件が発生したとすると，その影響範囲がどこまでなのか把握するのは至難の業になる。また，チューニングを実施する場合では，あまりにも深いネストをもつオブジェクトを参照するSQL文のチューニングは困難を伴う作業となる。

アプリケーションのテストでデータ・フローを追えない
　また，ビューやトリガーは，データベース内でビジネス・ロジックの一部が実行されているにもかかわらず，アプリケーションからは中身が見えず，ブラックボックスである。小手先の回避策としてこれらを多用してしまうと，データベースとアプリケーションの間に大きな壁ができてしまう