多态数据库设计:这种方法有名吗？

Question

我有一个基础enitiy(项目),将托管大量的项目类型(> 200)与完全不同的属性.我想要一个干净的便携式和快速的解决方案,并想出了一个maby有一个我不知道的名字的想法.

在这里:

• items-entity包含基类字段+子类字段的附加字段,但带有dummie-names,ItemID,ItemNo,ItemTypeID,int1,int2,dec1,dec2,dec3,str1,str2

• 引用的itemtype-record包含类型和子enity的名称(1:n):

• itemtypefields [itemtypeid,name,type,realfield] [53,MaxPressure,dec,dec3]中的示例

它的局限性:

• 难以估计基类中的字段要求
• 更难根据子类型添加域/检查约束
• 需要应用层将标记的sql转换为真实的查询
• 由于可以将共享属性定义为不同的"实际字段",因此一次只能查询一种类型.

第3个子弹解释:

select ItemNo,_MaxPressure_ from items where ItemTypeID=10 and _MaxPressure_>42
should translate to:
select ItemNo,dec3 as MaxPressure from items where ItemType=10 and dec3>42

(不能用sp或udf这样做 - 或者可能吗？)

但益处:

• 性能
• 易于CRUD操作
• 更容易在应用程序级别进行排序/筛选.

现在 - 它有名字吗？

Answer 1

此反模式称为One True Lookup Table.

在关系数据库中,每列需要定义为一种逻辑类型.我不是指一个像INT或VARCHAR这样的SQL数据类型,我的意思是该列中从开始到结束的所有内容都必须来自同一组值,并且您应该能够将一个值与另一个值区分开来.

您不能将鞋子尺寸和平均温度以及每英寸的线程放入给定表格的同一列中,并且仍将其称为关系.

基本上,您的数据库根本不是数据库 - 它将是一个电子表格.

阅读CJ Date的几乎所有书籍,例如SQL和关系理论,以正确解释关系和类型.

你的评论:

在阅读关于初级书籍和嘲笑半结构化数据之前,再次阅读Q.

好的,我重新阅读了你的帖子.

One True Lookup Table的经典用法并不完全是你正在做的,但你所做的与OTLT有着同样的问题.

假设您在dec3ItemType 10的列中存储了"MaxPressure" .假设MaxPressure的值有一组固定的有效选项,并且您希望将这些选项放在另一个查找表中,这样就没有人可以输入无效的MaxPressure值.

现在:在dec3上声明一个引用MaxPressures查找表的外键约束.你不能 - 问题是外键约束适用于所有行中的dec3列,而不仅仅是ItemType为10的那些行.

原因是您在一列中存储了多组值.任何其他类型的约束都会出现同样的问题 - 唯一约束,检查约束,甚至NOT NULL.并且您也不能为列声明DEFAULT值,因为您可能对每个ItemType具有不同的正确默认值(并且某些ItemTypes对该列没有默认值).

我之所以提到CJ Date书,是因为他为一个类型提供了一个清晰的定义:它是一个命名有限集,在其上定义了相等操作.也就是说,您可以判断一行中的值"42"是否与另一行上的值"42"相同.在关系列中,必须为true,因为它们必须来自相同的原始值集.在你的表中,dec3当它是MaxPressure时可以具有值"42",但是当它是每英寸的线程时,可以具有"42"作为另一个ItemType.因此他们是不相同的值"42".如果你有一个独特的约束,这两个42不会被视为重复.如果你有一个外键,每个不同的42将引用一个不同的查找表,等等.

你正在做的不是一个有效的关系数据库设计.

除非你理解这一点,否则不要指责我关于关系数据库设计的资源.