石橋秀仁＠Jobwebです。こんにちは。
ono@....jp wrote:
> 小野です。
> 私は、クラス構造の変更と RDB の同期をとることは、「何らかのメカニ
> ズム」で可能だと思うので、これがリファクタリングの本質的な障害に
> はならないだろうと楽観的に考えています。しかし DB のスキーマだけ
> は、実運用に回すまでにカッチリと固定するくらいの気持で「前払い」
> 設計をしなくてはいけないので、リファクタリングできない == XP は
> 適用出来ないのではと予想していますが、でもなんかいい方法ないかな〜
> とも考えています。
基本的なことかもしれませんが、ひとつのアイデアがあります。
●テスト段階に入ってからも DB スキーマを変更するための仕組み：
素の表（テーブル）にアクセスしない ＝ 視点（ビュー）からアクセスする
というルールです。
というようなことが、SRC から出ている
『実践!!データベース設計バイブル』 鈴木 昭男
http://www.amazon.co.jp/exec/obidos/ASIN/4883731170/
に書いてあります。とくに、270 ページの
第４部 パフォーマンス設計 ３．２ データベース設計のポイント
（３）設計変更に対処できる仕組みを作っておく
の部分がこれに該当します。
***
テーブルへのアクセスをビューからのみに限定することで、
もともと一つの表を分割した場合（正規化）や、それにともなう
SQL 文の変更（結合 JOIN など）にも対処できます。
属性の追加の場合にも、直に表へ属性を追加する（ALTER TABLE）
ことも、別のテーブルを作って外部参照制約をかけて外部結合する
こともできます。そのどちらの場合でも、プログラム上では同じく、
「ビューに属性が１つ増えた」ように見えます。
そして、ビューからのアクセスによる結合処理などが、
パフォーマンス上のボトルネックとして無視できなくなったら、
そこでテーブルの再構成（関連する表を一つの表として
まとめて表の再定義）をします。その際にもプログラムの
変更は１行も必要ありません。
なお、再構成後はビューの定義は、素通し、例えば
CREATE VIEW V_FOO AS SELECT * FROM V_FOO
のようになります。これなら結合処理などによるパフォーマンス
低下は、ほとんど無視できる程度になります。
ということで、RDB のスキーマレベルの話はこれで解決するのでは
ないでしょうか？
RDB と OO のマッピングは、また別のレベルですね。
＃XML を使ったマッピングには興味あります。
では。
--
石橋秀仁 hideto-i@....jp
messenger: ICQ# 83329246, MSN hideto_i@....com, Yahoo! hideto_i