2

現在、ユーザー定義フィールドを実装する必要があるシステムを構築しています。

私は現在、次のEAVのような構造を持っています。「Person」テーブルは、マスター テーブルとして機能します。

人物表

PersonID(PK)
PersonName

データフィールド テーブル

FieldID(PK)
FieldName
FieldType

DataFieldValue テーブル

ID(PK)
DataFieldID(FK)
PersonID(FK)
StringValue
IntValue
LongValue
DateValue
DateAdded
DateUpdated

この構造をプロトタイプでうまく使用することができました。ただし、非常に多くのレコードに対応する必要がある私の生産システム。私の好みはこのアプローチに固執することですが、「DataFieldValue」テーブルはかなり大きくなる可能性があります。

これは本番システムで安全でしょうか、それとも何らかの形で分解したほうがよいでしょうか?

SQL Server と ASP.net MVC 4 (EF 5 を使用) を使用しています。

4

1 に答える 1

1

データ フィールドの値に対してクエリ (SELECT) を実行する必要がない限り、私は非常に根本的なアプローチを取り、no sql + JSON の利点を追加します。

これは、私の Person テーブルのデータがどのように見えるかです

ID PersonName ExtraProperties
----------
1  ABC        [{'FieldId':1,'FieldName':'Age', 'Value':22},{'FieldId':2,'FieldName':'Gender', 'Value':'Male'}]

JSON.Netなどのライブラリを使用すると、このコンテンツをシリアル化および逆シリアル化し、コード内で使用できます。

データに対するアドホック クエリ (このスキーマでも難しい)、一貫性 (fieldid が一致しない可能性があります) などは失われますが、パフォーマンスと使いやすさは向上します。

また、C# のダイナミクスを調べて、役立つかどうかを確認することもお勧めします。

于 2013-06-05T09:45:02.647 に答える