0

多くの「複雑な」フィールドを含む「プロジェクト」エンティティ/クラスがあります。たとえば、さまざまな実装が可能なインターフェイスとして参照されます。例を挙げると、事実上任意の型 (私が実装したのと同じ数の型) の T を持つインターフェイス Property です。

JPAを使用しています。これらのフィールドについては、実際にシリアル化して保存するしかありませんでした。クエリでこれらのオブジェクトを使用する必要はありませんが、これは明らかにいくつかの問題につながります。たとえば、最初のメンテナンス/更新などです。

2 つの質問があります。

1)シリアライズされたクラスに「重大な」変更があった場合に備えて、データベースを最新の状態に保つために検討できる「トリック」はありますか (ほとんどの場合、シリアライゼーションの変更は適切に処理されます)。

2) JDO への移行は役に立ちますか? 私は JDO の経験がほとんどありませんが、私の理解では、JDO ではテーブル内のオブジェクトをシリアル化することは決してありません (ただし、変更はどのように処理されますか?)。2) をサポートするために、私が持っているオブジェクト グラフは非常に複雑になる可能性があることも付け加えなければなりません。たとえば、完全な「プロジェクト」を取得するためだけに数十のテーブルが必要になる可能性があります。

4

1 に答える 1

0

JDO は明らかにインターフェイス フィールドの永続性をサポートしています (ただし、DataNucleus JPA もそれらの永続性をベンダー拡張として許可しています)。一部のインターフェース フィールドが考えられる型の 1 つであることは、JDO 自体ではなく、RDBMSに問題を引き起こします。基礎となるデータストアは、(モデルを適切にミラーリングできないという点で) 問題であり、他の多くのデータストアの 1 つがその問題を解決するのに役立ちます。たとえば、DataNucleus JDO/JPA は、GAE/Datastore、Neo4j、MongoDB、HBase、ODF、Excel などをサポートし、関連オブジェクトの「id」を所有オブジェクト表現の「列」(または同等のもの) に保持するだけです ...したがって、そのような重大な変更は、現在のものよりもはるかに少なくなります。

于 2013-03-27T13:44:50.400 に答える