 |
開発フェーズで，データベース設計とアプリケーション設計との間で仕様の認識が異なっていることがよくある。そのようなとき，データベースもしくはアプリケーションのどちらかで仕様変更を吸収する必要に迫られ，ビューやトリガーといったデータベースとアプリケーションの中間に位置するグレーな部分で回避する場面をよく見かける。
これは，構築したデータベースへの変更とアプリケーションへの変更を最小限に抑えるテクニックの一つである。しかし，このグレーな部分での回避策を多用すると，今後のデータベース，アプリケーション双方のメンテナンス性に対して大きな禍根を残すことが多い（図1）。
 |
| 図1●ビューやトリガーを多用することによる問題 [画像のクリックで拡大表示] |
カラムを一つ削除するのも大変
確かに，ビューやトリガーは，使い方によってはアプリケーションで考慮しなくてはならないことをデータベース側で吸収できる優れた機能である。しかし，データベースから見ればビューやトリガーは通常のオブジェクトとは異なる特殊なオブジェクトと見ることができる。
通常のオブジェクトは，（参照整合性制約などはあるが）単独で機能する。しかしビューやトリガーは単独では機能し得ない。複数のオブジェクトに依存して機能するオブジェクトである。この依存関係を正確に理解しておかないと，後の仕様変更やチューニングで面倒なことになる。
きちんとした設計もなく小手先のテクニックとしてビューやトリガーを放置しておくと，ビューに対するビューや，そのビューに掛けられたトリガーなど深いネストを持つオブジェクトが生まれてしまう。
このような場合，あるテーブルのカラムを削除したい要件が発生したとすると，その影響範囲がどこまでなのか把握するのは至難の業になる。また，チューニングを実施する場合では，あまりにも深いネストをもつオブジェクトを参照するSQL文のチューニングは困難を伴う作業となる。
アプリケーションのテストでデータ・フローを追えない
また，ビューやトリガーは，データベース内でビジネス・ロジックの一部が実行されているにもかかわらず，アプリケーションからは中身が見えず，ブラックボックスである。小手先の回避策としてこれらを多用してしまうと，データベースとアプリケーションの間に大きな壁ができてしまう（図2）。
 |
| 図2●ビューやトリガーはデータベースとアプリケーションの間の壁 [画像のクリックで拡大表示] |
特にトリガーには注意が必要である。トリガーはアプリケーション開発者に全く気づかれずにデータを操作する。時にはデータベース管理者でさえこの状況を把握していない場合がある。
アプリケーションのテストを想定してみよう。内部で誰も認識していないデータ操作をするデータベースでは，そのデータ・フローを追うことすら困難を極める。
あるいは，アプリケーションの拡張に伴い一部のテーブルを拠点データベースに公開し，その開発も移管する場合を想定してみよう。公開するテーブルに場当たり的に設計したトリガーが付いていた場合，トリガーという重要な情報が他の開発者に確実に伝わるだろうか。
データベースとは，設計段階で理想的なデータ構造を検討し構築してあるはずである。アプリケーション側ではそのデータ構造を最大限に活用すべきであるし，初期のデータベース設計に誤りがある場合は，小手先のテクニックで逃げることは避けなければいけない。根本的な原因を追究し，そこにメスをいれる勇気が必要である。
|
