拡張可能なデータベーススキーマ - 拡張可能な属性値を格納する方法

Question

私たちはSQL Server 2008を使用しています。要件の1つは、システムに対して定義されたエンティティの拡張可能なユーザー定義属性を持つことです。たとえば、Doctorというエンティティがあるとします。システムの管理者が通常はシステムにない追加の属性を定義できるようにします。これらの属性は、親テーブルまたは結合テーブルをリンクするクエリ条件として必要になる可能性が最も高いです。

属性（名前、説明、タイプ）などを定義するテーブルがありますが、私の質問は実際のデータ値の格納にあります。

イムないDBA（1をふりだけのプログラマ）が、私の最初の考えは

nvarchar(450) 

これは基本的なタイプのほとんどをカバーし、まだ可能になるように、1つの汎用の列に保存することでした私は変換の種類の問題（日付、数値などに変換する）だけでなく、すべてがnvarcharなので、異常なクエリの問題に遭遇すると思った。

だから、私の最新の考え方は、私たちがサポートする各データ型の列を作成することです：

ColNVarCharData 
nvarchar(450) 

ColBitData 
bit 

ColIntData 
int 

..Andなど

ユーザーが拡張属性を定義したとき、彼らは選ぶだろうその型のその列に属性値を格納します。たとえば、intを選択した場合、データ値はColIntDataに格納され、他の2つの列はこの例ではnullになります。

これは、各属性をジェネリック型として格納するのではなく、変換の問題を解決すると考えています。さらに、使用されているクエリに応じて、各タイプの必要に応じてインデックスを追加できます。

私はこれを使用する方に傾いていますが、他に誰かの提案があるかどうか疑問に思っています。私はXMLデータ型を細かく見てきましたが、「スキーマ」が頻繁に変更される可能性があるため、これはより適切だと思いました。

Answer 1

ここには、このトピックに関連するいくつかの質問/回答があります。

• One
• Two
• Three

Answer 2

@gbnはコメントで私を送ったリンクに基づいて、私はこれが（から撮影効果的な答えだと思いますWIKIリンク）：

シンプルですが、非スケーラブルで、構造中に0

値

上記のEAVデータの例のように、文字列の中にすべての値を強制変換、結果：1を使って何をしたい場合には、一定のデータ型間の変換が必要とされていますEAV表の値列の索引は本質的に無用です。また、小さな整数や文字列と同じテーブルにBase64でエンコードされた形式で、イメージなどの大きなバイナリデータを格納することは便利ではありません。したがって、より大きいシステムでは、各データ型（バイナリラージオブジェクト「BLOBS」を含む）ごとに別々のEAVテーブルを使用し、データが格納されるEAVテーブルを識別する特定の属性のメタデータを使用します。このアプローチは実際には非常に効率的です。これは、ユーザーが操作するために選択された特定のクラスまたはフォームの属性メタデータの量をメモリに簡単にキャッシュできるためです。ただし、属性のデータ型が変更された場合、あるテーブルから別のテーブルにデータを移動する必要があります。 （これは頻繁ではありませんが、データベーススキーマ設計の場合と同様にメタデータ定義で間違いが発生する可能性があります）。