3

Len Silverston の Data Model Resource Book Vol. 3、1 つはタイプとカテゴリ: 分類用、もう 1 つは階層、集約、およびピアツーピア関係用です。基本的には、次のように実装されます。

分類

[エンティティ] (M x M) [エンティティ タイプ] (M x M) [エンティティ タイプ タイプ]

...ここで、(M x M) は、分類テーブルによってデータベースに実装された多対多の関係です。

協会

上記のエンティティ テーブルとタイプ テーブルには、独自の型付きロールアップもあります。

  • [エンティティ] (M x M) [エンティティ]
  • [エンティティタイプ] (M x M) [エンティティタイプ]
  • [EntityTypeType] (M x M) [EntityTypeType]

...ここで、各 (M x M) は、ロールアップ/関連付けのタイプへの外部キーを持つロールアップ テーブルに実装された多対多の関係です。

結果として得られるデータ構造は、エンティティとそれらの相互関係の両方を記述するという点で、非常に優れた表現力を提供します。ただし、アプリケーションでこの表現力を活用するのに問題があります。主な問題は、EF 4 および 5 の進歩にもかかわらず、M-2-M 関係は依然として複雑であり、データベースにアクセスするたびに少なくとも 2 方向で M-2-M 関係にアクセスしようとしていることです。これは、次の点で特に複雑です。

  1. [エンティティ] と [エンティティ] のいくつかのサブタイプの両方をサブタイプ化します。
  2. すべての M2M テーブル (すべての分類およびロールアップ/関連付けテーブル) には、少なくとも From と Thru の日付を含むペイロードがあります。ロールアップには、少なくとも 1 つのロールアップ タイプも含まれます。
  3. エンティティにアクセスするたびに実行時にデータを解釈するために、タイピング スキーマ (EntityTypeType テーブルとそのロールアップ) の大きく離れた部分を読み込む必要はありません。

技術:

  • SQL Server 2008 R2
  • エンティティ フレームワーク 5
  • .NET 4.5
  • MVC 4 (Web アプリ部分には、いくつかのコンソール アプリもあります)

モデル自体に関する質問:

  • これは単に .NET で機能しないデータ モデルですか?
  • 最初に、データベースを基本的にビジネス オブジェクトをモデル化する .NET に適したビューにフラット化する必要がありますか?

型付けスキームに関する質問- 型はかなり静的であることに注意してください。

  • [EntityType] テーブルと [EntityTypeType] テーブル、それらの分類、およびそれらのロールアップを C# クラスにスキャフォールディングする必要がありますか? これは enum scaffolders と同様に機能しますが、これらにはペイロードの日付範囲とタイプ ペイロードがあるため、name/int 以外のものが必要です。もしそうなら、それらのファイルを静的クラスとして足場にする方法についてのいくつかのアイデアは何ですか? ハードコーディングされたオブジェクトリスト?
  • 代わりに、起動時にタイピング スキームをキャッシュする必要がありますか (コンソール アプリの起動に多くのオーバーヘッドが追加されるため、これは気になります)。
  • 他のアイデア - 足場の XML ファイルはありますか? 等...

どんなアイデアや経験も大歓迎です！

4

2 に答える 2

2

私はそれぞれの質問に答えようとしましたが、実行時にデータベース上にエンティティを動的に作成しようとしているのか、実行前にエンティティを動的に作成しようとしているのかわからないことを認めなければなりません。

SQL Serverのスキーマが変更されたときに動的に変更/調整するコードをリリースしようとしている場合は、いくつかの異なる答えがあります。=）

これは、.NETでは単に機能しないデータモデルですか？

あなたが私に目立ったと言ったいくつかのこと：

  1. MxMの関係がたくさん。
  2. Entity / EntityType / EntityTypeType
  3. ロールアップ

読んだ後に私が持っているいくつかの質問：

  1. すべてが簡単になることを期待して、データをモデリングするためのフレームワークを選びましたか？
  2. フレームワークを選択したのは、それを行うための「正しい」方法のように思えたからですか？
  3. データをどのようにモデル化したかを理解するのに苦労しています。EntityTypeTypeとは正確には何ですか？
  4. すべてのMxMの関係は本当に必要ですか？エンティティAとエンティティBがMxMの関係にある可能性があるという理由だけで、それらは必要ですか？

あなたのドメインはわかりませんが、あなたの説明を理解するのに苦労していることは知っています。=）私の意見では、2つの理由ですでにある程度機能しなくなっています：1）あなたはそれについてSOに尋ねています、b）たくさんのテキストなしで説明するのは簡単ではありません。

まず、データベースをフラット化して、ビジネスオブジェクトを本質的にモデル化する.NETに適したビューにする必要がありますか？

はい！

少なくとも私の経験から、私はそう言うでしょう。=）

複雑な関係を持つエンティティをデータベースに作成しても問題ないと思います。親/子、ピアツーピア、階層など。すべて正常で良好で正常です。

しかし、アプリケーションはそれを理解するためにそれらすべてを解釈する必要はありません。データベースは、結合、データのグループ化、ビューの作成などを行うのに適しています。少なくとも読み取りに関しては、ビジネスオブジェクトにできるだけ近いビューまたはストアドプロシージャを作成することをお勧めします。

また、オブジェクトをアプリケーションに関連付ける複雑さを押し上げると、パフォーマンスが低下する可能性があることも考慮してください。

[EntityType]テーブルと[EntityTypeType]テーブル、それらの分類、およびC＃クラスへのロールアップをスキャフォールディングする必要がありますか？

私はこれに反対することをお勧めします。唯一の理由は、現在、アプリケーション層でデータベース作業を行っていることです。結合/ロールアップなどを実行する場合。データベースではなく、アプリケーションでそのデータを管理しています。

すでにこれを知っていると思いますが、データベース内のすべてをアプリケーションに戻し、クエリを実行したり、オブジェクトを構築したりすることは避けたいと考えています。

SQL Serverは、オブジェクトを関連付けたり、さまざまなエンティティをまとめたりするのに優れています。そのレイヤーでは非常に高速になります。

ビジネスオブジェクトを作成し、SQLからそれらにデータを入力します。

EntityType / EntityTypeTypeをスキャフォールディングする必要がある場合は、N+1の問題が発生しないように注意してください。

これらのファイルを静的クラスとしてスキャフォールディングする方法について、いくつかのアイデアはありますか？ハードコードされたオブジェクトリスト？

オプション：

  1. ORMを使用して、クラスを生成します。あなたはすでにEFでそのいくつかを見てきました。
  2. エンティティのSQLServerスキーマを調べて、独自のコード生成ツールを作成します。
  3. 生成されないクラスを手動で記述します。私はこれがいつも行われているのを見ます、そしてそれはあなたが思うほど悪くはありません。確かにいくつかのうなり声は働きますが、柔軟性も与えます。
代わりに、起動時に入力スキームをキャッシュする必要があります（コンソールアプリの起動に多くのオーバーヘッドが追加されるため、これは気になります）？

アプリケーションのロード時にエンティティに基づいてビジネスオブジェクトを生成しますか？または、質問を言い換える別の方法...実行時にプロキシクラスを生成しますか？

于 2013-03-04T18:02:12.097 に答える
1

私はLenSilverstonの本に精通しておらず、StackOverflowユーザーの大多数もそうではないと思います。3日以内に質問に対する回答が得られなかったので、とにかくコメントします。

あなたのデータベースモデルで奇妙なことに私を驚かせるのは、あなたが複数のネストされたN：M関係を持っているように見えるということです。真のN：M関係が存在することはめったにありません-ほとんどの場合、N：Mリレーショナルモデルの中間テーブルは実際に実生活に存在するオブジェクトを表し、2つの通常の1：N関係と2つ以上の列が残りますリンクテーブル。過去25年間で1つか2つの真のN：M関係に出くわしただけなので、実際に3つあるのではないかと思います。あなたがそう思う方法。

あなたが説明することは、データベース内のデータベースをモデル化しようとしているようなにおいがします。特に、「最初にデータベースをフラット化して、ビジネスオブジェクトを本質的にモデル化する.NETに適したビューにする必要がありますか？」魚のように聞こえます。ごくわずかな例外を除いて、データベーステーブルは最初からビジネスオブジェクトと一致する必要があります。実際のオブジェクトを表示するためにフラットビューを作成する必要がある場合は、完全に間違った方向に向かっている可能性があります。しかし、繰り返しになりますが、あなたが提供した情報から見分けるのは困難です。

あなたがやろうとしていること、これまでにやったことについて、より抽象的な説明をしてください。

于 2013-03-01T12:41:58.660 に答える