2009-07-18 3 views
4

私は最近、EAVデータベース構造に大きく依存しているシステムを継承しており、パフォーマンスの観点から本当に苦労しています。eavをnhibernate/ormでサポートできますか?

私がしたいことは、nhibernateまたは他の適切なORM製品を使用して、これらのEAVテーブルをエンティティにマッピングして、行をプロパティにマップできるようにすることです。データベースをリファクタリングしてリレーショナルにすることができます。これが可能なら誰でも知っていますか?一例もありがとう! :)

あなたの構造のための感じを与えるために、それはこのようなものになりますように

エンティティ(実体識別子) EntityVarchar(実体識別子、VarcharValue) EntityFloat(実体識別子、VarcharValue)

をし、 。私がCustomerエンティティを持っていたら、Customer.Varchar ["Name"]ではなく、Customer.Nameという名前を取得すると言っています。

私たちのシステムにEAVモデルを使用する必要はありません。私たちはデータ構造の実行時の変更を許可していませんので、とにかくそれは悪い習慣だと思います。

答えて

1

これは簡単ではないと思います。データベース・スキーマを読んで適切なマッピングとクラスを生成できるジェネレータが存在するにもかかわらず、これは既存のeav dbのアクセス・レイヤーに過ぎません。このデータベースのリレーショナルバージョンを生成するには、データを読み込んで、dbに設定された値のプロパティを含む新しいドメインオブジェクトを作成する必要があります。 これは、eav dbに存在するすべてのプロパティを含む1つの大きな表になる可能性があります。そのため、既存のデータを手作業で分析し、アプリケーションのニーズを考慮してリレーショナルDBモデルを作成する方が良い方法だと思います。特にテーブル継承はあなたの友人になるはずです。 両方のスキーマのアクセスレイヤーを作成した後でも、データ移行用のマッピングを作成する必要があります。

+0

nHibernateを使用すると、dbスキーマと1:1マッピングではないようにエンティティをクラスにマップできます。したがって、自分自身を強くデータベースに結合する必要はありません。 複数の行をマッピングする瞬間に、各プロパティのオブジェクトを1つのオブジェクトにマッピングする方法がありません。通常、単一のオブジェクトのデータを含む1つの行があります。 – spooner

+0

私は知っていますが、あなたが既に言及した方法以外の方法であなたが望むことをする可能性は全く見ません。 filter-propを多対1に使うことはできますが、何も助けにならないかもしれませんし、とにかくパフォーマンスの問題を解決するのに役立つとは思わないでしょう。 多分私はあなたが間違っていますが、理解しているように、リレーショナルまたは混合スキーマにeavをリファクタリングすることを検討しています。貴重な小道具をバッグやセットに入れておくだけで、必要に応じてロードすることができます。 – zoidbeck

+0

問題は本当にプロパティバッグが必要ないということです。新しいプロパティを追加するのは開発者だけです。ユーザーがモデルを拡張することは期待していません。 基本的に私が継承したシステムは、このEAV構造体を使ってフレームワークから構築されています。我々は、完全に正規化されたモデルが今後必要である。ドメインモデルをベースラインにしてデータベース作業を開始できるように、私が提案した方法でマッピングを実行できることを期待していました。 あなたが言っていることはこれが可能ではないことです。これは残念ですが、唯一の解決策は手作りのDALだと思われるからです。 – spooner

関連する問題