オプションの構造のSQL

Question

DBの世界は私のものではないので、おそらく質問が（データ型など）の項目の異なる種類のデータを保存DBの設計を想像し

簡単です

私は私が何をすべきか見当がつかないそれが、私は比較することができソフトウェア経由してアイテムのすべての種類は、それぞれのタイプ

の性質を持つテーブルになるため、これは、私はそれを

id | quantity | price ... Kind | ID_k_foreing | 

を作ってるんですか種類、その後作る適切なテーブルこの擬似コード

switch(kind) 
{ 
case chess_game: 
     the join is made with a table like this: 
     id_k| material | length | weigth .. 
case car_toy: 
     the join is made with a table like this: 
     id_k| color | velocity | remote_control ... 
case doll: 
     the join is made with a table like this: 
     id_k| name | height | clothes .. 

... 

} 

トリッキーなソフトウェア機能を追加することなく、構造 で、この「データ型」の問題を解決するためにいくつかのstandarの方法がありますように

に参加しますか？

おかげ

Answer 1

あなたはこのquestionを見てみたいことがあります。

ビル・カールウィンのanswerはこのように分類します。

Single Table継承：すべての タイプのすべての属性を格納するための十分な 列を持つすべての製品の種類の一つのテーブル 、あなたはあなたが記述 型階層をモデル化するための、少なくともこれらの5つのオプション を持って

。これは多くの列があることを意味します。 行のほとんどはNULLです。

Class Table Inheritance： の1つのテーブル すべての製品タイプに共通する属性を格納した製品。次に、 製品タイプごとに1つのテーブルがあり、その製品タイプに固有の属性 が格納されています。

Concrete Table Inheritance：no表 一般的な製品の属性です。 代わりに、共通の製品 属性と製品固有の 属性の両方を格納する の製品タイプごとに1つのテーブル。

Serialized LOB： の1つのテーブル すべての製品タイプに共通する属性を格納した製品。 1つの特別な列 は、半構造化データのBLOBをXML、YAML、JSON、または他の 形式の に格納します。このBLOBを使用すると、 製品タイプごとに固有の属性を格納できます。 ファサードとメメモのような、これを説明するための派手なデザイン パターンを使用することができます。しかし、あなたに関係なく、 は、 がSQL内で簡単に照会できない属性の塊を持っています。 を持っていて、全体のブロブを アプリケーションに戻してそこに並べ替えます。

Entity-Attribute-Value： 製品の一つのテーブル、および行へ 属性、代わりの 列を旋回させる一つのテーブル。関係する パラダイムに関して、EAVは有効なデザイン ではありませんが、多くの人がそれを と使用しています。これは別の答えで言及されている "Properties パターン"です。 落とし穴のいくつかについては、Stackoverflowのeavタグ で他の質問を参照してください。

あなたはあなたのためにどの作品を選ぶ必要があります。