Entityの変更をDB(TABLE)に反映する機能は必要なのか？

昔から定型処理をなくすためDB(TABLE)のメタ情報からEntityクラスを自動生成する機能は沢山あった。

しかし、この自動生成には問題があり、色々な解決方法で対応されてきた気がする。

その問題というのが、DB(TABLE)の変更に伴うEntityの再作成にあった。

DB(TABLE)よりEntityを自動生成した後、開発者がEntityにプロパティやメソッド内にロジックを追加・修正してしまったあと、テーブルの修正が発生してしまった場合だ。

単純に自動生成し直すと、開発者が追加したソースは上書きされなくなってしまう。

~~Troque~~Torqueは解決方法としてGeneration Gapパターンで、この問題を解決した。

HOGEテーブルから自動生成されるEntityは、HogeBase.javaとHoge.javaの2つのソースが作成され、Hoge.javaはHogeBase.javaを継承した親子関係のクラスになる。

テーブルの情報は全てHogeBase.javaに定義され、開発者はHoge.javaを拡張するパターンだ。

このパターンにより、2度目以降の自動生成では、HogeBase.javaのみ作成され開発者が手を入れたソースは保全されるようになる。

しかし、この方法にも弱点があった、1つに1テーブルに2Entityが存在することになる。クラスの増大が発生する。

まぁ個人的には1テーブル,2クラスでも決めごとであれば問題ない範囲とは思っているが、問題になるのはHoge.javaは拡張用の空クラスである。

拡張する必用のないEntityにも2クラス出来てしまうため空クラスが横行してしまうのは頂けない。

また自分の思いだがGeneration Gapパターンは意外と利便性(可読性)が悪いのだ。

だんだん、本筋からずれてしまうという得意のパターンになってきたが、聞きたかった事はタイトルの通りで「Entityの変更をDB(TABLE)に反映する機能」は必要となるのかという事になる。

この機能は、要はプルグラムを中心にデータストアを決めるという視点で、それ自体は間違いではないと思うし、その思考のなかで、「で、あれば」プログラムの内容をDB(TABLE)に反映させるのが自然である。という流れは理解できる。

しかし、個人で開発しているシステムならともかく、ある機能を担当するプログラマが必要であるからといってテーブル項目名や型を変更したり、項目の追加や削除をする又はテーブルそのものを追加・削除することはあり得るのだろうか？

仮に項目の追加・変更等を行った時に、どのくらいの影響があるかを調査する機構（機能）は費強いうだと思うが、実際に1担当者の独断で項目の追加・変更を行う事があり

得るのだろうか。どーも想像できない。。。そう考えると「Entityの変更をDB(TABLE)に反映する機能」は不要な気がする。

どーなのだろう（・・？

皆さんの考えをしりたい。。。

追記
EntityクラスからDB(TABLE)の自動背性機能はあっても良いとは思うけど…やっぱ微妙な気がする（--；)