2

ID、名前、説明などの共通フィールドを共有する一連のタイプを持つデータモデルに取り組んでいます。より具体的には：

Document クラスには属性のリストがあります。これらの属性は私たちのドメインにあり、String、Integer、DateTime などの型と、Address や String、Integer、Address などのリストなどのより「複雑な」型です。共通の属性 (Id、Name、Description) を含み、適切なサブクラスでより具体的な属性を持つ抽象基本クラス (AttributeBase)。例: StringAttribute (値)、IntegerAttribute(値)、AddressAttribute (Street など)、StringListAttribute、IntegerListAttribute、AddressListAttribute。15 ～ 20 の異なるサブクラスについて話しています。しかし、これらのクラスをデータベースでどのようにモデル化しますか? TPH、TPT、TPCのどれを選びますか? TPT と EF 4.1 を選択したときのパフォーマンス ヒットについて読んだことがありますが、TPH に 1 つの大容量テーブルを使用すると、パフォーマンスが低下しません。パフォーマンスが良くても、私には正しく聞こえません。テーブル内の潜在的に 10000 ～ 1000000++ 行のデータについて話している。

これらのシナリオに関して、直接の経験はありますか? この件に関して、私は本当にあなたからここにいたいと思います。

4

1 に答える 1

5

TPHは、DBの観点からは適切に聞こえませんが、実際には、このタイプのメタデータを使用する多くの製品で使用されるストレージモデルです。例はSharePoint（2007）で、すべてのデータが1つのテーブルにあります。より複雑なモデルに従いますが、基本は同じです。SharePointとそのデータの保存方法は好きではありませんが、問題について考えると、大量のデータをサポートする汎用ソリューションをモデル化するためのより良いソリューションは見つかりませんでした。

TPTとTPCはDBでより正規化されているように見えますが、それらを使用するとアプリケーションが遅くなります。さらに、、および整数を使用した2番目のテーブルへIntAttributeの正規化は、ほとんどの場合、IMHOで正規化されています。IdNameDescriptionIdValue

ところで。ドキュメントで何かをしているときに、ドキュメントにプロパティを割り当てたい場合は、Sharepointをチェックする必要があります。これにより、すぐに使用できるようになります。

于 2011-10-12T10:28:42.690 に答える