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 ..
...
}
有一些标准的方法可以解决结构中的“数据类型”问题
没有添加棘手的软件功能?
谢谢
最佳答案
您可能想看看这个question。
Bill Karwin的answer用这种方式将其分解。
您至少有这五个选择
用于建模类型层次结构
描述:
Single Table继承:一张表
适用于所有产品类型
列来存储所有的所有属性
类型。这意味着很多列,
其中大多数在任何给定条件下均为NULL
行。
Class Table Inheritance:一张桌子
产品,存储共有的属性
所有产品类型。然后每个一张桌子
产品类型,存储属性
特定于该产品类型。
Concrete Table Inheritance:无表格
常见商品属性。
相反,每种产品类型一个表,
储存两种普通产品
属性和特定于产品
属性。
Serialized LOB:一张桌子
产品,存储共有的属性
所有产品类型。多一列
存储半结构化数据的BLOB,
以XML,YAML,JSON或其他形式
格式。该BLOB允许您存储
每个特定的属性
产品类别。您可以使用精美的设计
描述这种情况的模式,例如
立面和纪念品。但是不管你
有一堆不能
可以在SQL中轻松查询;你有
将整个Blob取回
应用程序并在那里进行排序。
Entity-Attribute-Value:一张桌子
产品和一张可旋转的桌子
属性,而不是行
列。 EAV不是有效的设计
关于关系
范例,但是很多人使用它
无论如何。这是“属性
模式”由另一个答案提到。
使用eav标签查看其他问题
在StackOverflow上的一些
陷阱。
您必须找出最适合您的一种。