ひがさんの提唱する「プログラミングファースト開発」で困難だと思われるのはDB設計だ。
本家ブログのコメント欄でも言及されてる。
要件定義は、プログラムファースト設計の前に行うということでいいと思いますが、DB設計は、作りながら変わっていくと思うので、プログラムファースト設計と同時にするのがよい(しかない)と思っています。
http://d.hatena.ne.jp/higayasuo/20080501/1209636051
ツールでリファクタリング機能が、いかに整ったとしても
RDBのリファクタリングがアプリケーションに及ぼす影響は計り知れない。
SQLServerは、機能が豊富でRDBMS的にかなり融通が利くほうだが、
機能だけでDBのリファクタリングが可能かといえば、まったくそうではない。
開発途中では、列や値の業務的な意味づけが変わることも多々ある。
また、DBのリファクタリングは開発と並行で進めるべきだが、
そのたびにアプリがエラーになるのでは、顧客に不信感を植え付ける。
顧客に見せながらの開発が前提なので、特に気をつけたいところだろう。
こういうときこそ、「ViewベースDB設計」*1をお勧めしたい。
簡単に言って（難しく言っても）ViewによるアプリとDBの疎結合だ。
手順は以下。
- データアクセス単位で、とりあえずほしいデータを適当に詰め込んでテーブルとする。
- ただし、Viewを介したデータアクセスとしておく。
- 仕様が固まってきたタイミングで、DBリファクタリング
データアクセス単位にViewを作ることになるが、
DBAとしては、RDBMS内にクエリが保存されているほうが何かとメンテナンスしやすい。
パフォーマンスが気になるなら、後々チューニングフェイズを設ければよい。
そもそもパフォーマンスチューニングの原則は、
「開発中はチューニングを意識しない」だから、その点は気にしなくてよいと思う。
システム開発の要件として、既存データがまったく無いことは考えにくいし、
新規事業のシステム化であっても、Excelなり、紙帳票なりがあって、それらをインポートするのは必須だろう。
その上、既存システムのデータ取り込み方法のいかんによって要件が大きく変わることもあるので、
DBリファクタリングを避けては通れない。
プログラミングファースト開発であろうとなかろうと、
DBとアプリの間に層をかませることはメリットがあるのではないだろうか？
