1

私は最近、データベースを改良し、多くのエンティティを正常化するプロセスを経ました。明らかに、以前よりもテーブルがいくつか増えました。Web サイトで使用するデータの多くは読み取り専用であるため、ビューを使用して非正規化するのは簡単ですが、非正規化された取得の恩恵を受けるエンティティもありますが、それでも更新する必要があります。

これが例です。

A User may be a Member
A Member may have a Profile
A Member may have an Account

さらに、さらに 3 つのルックアップ テーブルがあります。

合計で、User 用に 3 つのテーブル、Member 用に 4 つのテーブルがあります。

理想的には、上記のテーブルから 2 つのビューを作成できます。

ただし、メンバーに属するエンティティと同様に、ユーザーを更新する必要があります。さらに、Users/Members に関連付けられた 6 つの個別のテーブルがあります。つまり、FavouriteCategories も時々取得して更新する必要があります。

これを行うための最良の、最も効率的な方法を考え出すのに苦労しています。

ビューを使用してすべてのエンティティとルックアップをモデルに取り込むことはできませんが、取得クエリを生成するために EF に依存することになります。私が読んだことは、結合されたデータを扱うのに EF が最適ではないことを示唆しています。

テーブルを更新のみに使用して、ビューとテーブルの両方を追加できます。これは、モデルの重複、複雑さ、および EF モデルの機能の十分な活用が原因で、ずさんに見えます。

おそらく、データの取得に読み取り専用ビューを使用して、ストアド プロシージャを作成できます。ストアド プロシージャで EF を使用するプロセスはちょっとしたハックだと思うので、おそらくストアド プロシージャを EF とは別にして、単純に params を渡し、従来の方法で SP を呼び出します。これもまた、中途半端な家のようです。

私は .net や EF の経験があまりないので、上記で言及した方法またはこれを達成するためのより良い手法について、確かなアドバイスをいただければ幸いです。この段階で edmx ファイルをハッキングしたくありません。なぜなら、それは間違っているからです。

適切なソリューションの恩恵を受けるエンティティがいくつかあります。User の例は最も単純なものの 1 つであり、適切なアプローチから得られるものはたくさんあります。

ヘルプとアドバイスをいただければ幸いです。

4

1 に答える 1

1

EFを使いたいですか？はいの場合は、ビューをまったく使用せずに EF がすべてを処理できるようにする最初のアプローチを使用するか、ビューを使用してストアド プロシージャを挿入、更新、および削除操作にマッピングする最後のアプローチを使用します。

読み取り用のマップされたビューと変更用のマップされたテーブルを組み合わせることも可能ですが、これはほとんどの場合、クエリを最適化するための追加のビューを備えた最初のソリューション (EF がすべてを処理できるようにする) です。

よりクリーンなアプローチは見つかりません。言及されているアプローチは、問題の有効な解決策です。唯一の問題は、SQL を自分で作成するか (ビューとストアド プロシージャ)、または EF に任せるかということです。

最悪の方法は、クエリに EF を使用し、ストアド プロシージャを手動で呼び出して更新することですが、場合によってはそれが役立つこともあります。

于 2012-06-05T12:14:37.513 に答える