Sqlテーブルダイナミックセルのタイプ

Question

私はProductとProductTypeテーブルを持っているとしましょう。私は各製品タイプの特別な列を格納できるテーブルが必要です。特別な列（属性）は任意のタイプでよい。

今私は Product_%ProductTypeId%と呼ばれるテーブルを持っています。それは私が本当に好きではない解決策です - どんな提案ですか？

Id | ProductTypeId | ColumnName | Value | ColumnType 

、私はこれについては好きではありませんが、私は型の安全性を失うことだということですが、列ValueはIを意味するであろう文字列型のようになります。

私の考えは、colsの持つテーブルProductTypeColumnsを持っていることでした常に変換する必要があります。

さらに、このテーブルはレポートの生成に使用されます。「動的」列を持つことは問題になる可能性があります。

Answer 1

EAVと呼ばれます。
あなたはここにSO上EAVとSQL Serverに関するいくつかの質問を見つけることができます。

• EAV over SQL Server
• Performance of large EAV/open schema systems on SQL Server

それは異なった人々の多くは、異なる意見を持っています対象です。
Product_%ProductTypeId%テーブルを使用しなければならないと言う人もいれば、ProductTypeColumnsテーブルが良い方法だと言う人もいます。

基本的に、私はProductTypeColumnsキャンプにいます。
私たちは、同様の仕事で同様のものを使用しています：
私たちのテーブルには、注文アイテム（100万アイテム以上、2億5000万以上の属性）の属性が含まれており、現在では10年近く使用しています。
短所：型の安全性（すでに述べたように）とquerying can be a bit complicated。

私たちにとっては1000種類以上の属性があり、100種類以上の製品があり、各製品には100〜300種類の属性があるため、唯一の方法です。このような次元では、属性テーブルが唯一可能な方法です。
しかし、それはおそらく誰にとっても最高のソリューションではないし、それがあなたにとって最良の解決策であるかどうかわからない。

あなたの商品数と特殊属性がそれほど大きくない場合は、最初の提案（Product_%ProductTypeId%表）を手に入れることができます。
これは間違いなくクエリするのが簡単ですが、製品と属性の組み合わせが多すぎる場合は多分オプションではありません。

多くの場合、それは依存します。

Answer 2

カテゴリ階層（継承、サブタイプ、サブクラス）についてはどうですか？

私は個人的には列がない事前に決定されている場合にのみ、（あなたの質問に記載されている）の名前/値のペアのソリューションで行くと思います。

事前にすべての列がわかっていて、変更する可能性が低い場合は、カテゴリ階層while not without complicationsを実装すると、型の安全性が保持され、DBMSによる宣言的整合性の強化が可能になります（たとえば、 UNIQUE、FOREIGN KEY、CHECKのいずれかの制約）。