与数据库架构相关的问题

Question

我有一个关于数据库的理论问题.为了使它更具体,我想到了一个例子.

假设我有一个商店和产品.我有很多不同的产品.并非每种产品都具有相同的适用性.例如,我可以用千兆字节定义硬盘的大小,但不能在CPU上使用相同的属性,因为它不适用.我想要的是一个数据库,我可以动态地向产品添加属性.我唯一能想到的是以下内容:

一个带有ID,名称和描述的产品表.

一个属性表,包含ID,Product_ID,Property和Value.

通过这种方式,我可能会获得一个巨大的,我认为不那么高效的属性表.这已经困扰了我很长一段时间了.有谁知道我的问题更好的解决方案？

Answer 1

这实际上正在向第六范式转变,只是像你这样没有学术或经验背景的人不知道(a)它的名称和(b)规则和警告.这些人已经实现了通常所知的实体 - 属性 - 值或EAV.如果做得好,一切都很好,并且有数千个医疗系统在那里携带诊断和剂量信息.如果不是,则使用和维护一只狗的早餐.

1. 首先要确保你有Product真正的5NF.

2. 始终使用完整的声明参照完整性; CHECK约束和RULES.

3. 永远不要将所有这些都放入带有VARCHAR()for值的表中.始终使用正确(适用)的数据类型.这意味着您将拥有多个表,每个DataType一个表,并且不会失去控制或完整性.

4. 同样,任何关联表(其中存在对另一个表的多重引用[例如,供应商])必须是分开的.

   • 我提供的数据模型具有完整的控制权; 它包括一个简单的目录,可用于验证和导航.您需要添加每个CHECK约束并RULE确保数据和参照完整性不会丢失.这意味着,例如:
     • 为CPUSpeed列,其被存储在ProductDecimal,CHECK它是在值的适当范围
     • 对于每个子Product表CHECK,DataType对于ProductType-ColumnNo组合是正确的
   • 这种结构比大多数EAV好,而且不完全是6NF.
     .

5. 保留所有必填列Product; sub-Product仅将表用于可选列.

6. 对于每个这样的(例如Product)表,您需要创建一个View(虚线),它将从EAV/6NF表构造5NF行.您可能有几个视图:Product_CPU, Product_Disk.

7. 不要通过视图更新.将所有更新保留在存储过程中的事务处理中,并将每个列(即,适用于每个特定的表Product和sub-Product表)插入或更新到ProductType一起.

8. 巨大？商业数据库(不是免费软件)对大型表或联接没有问题.这实际上是一个非常有效的结构,并允许非常快速的搜索,因为这些表实际上是面向列的(不是面向行的).如果人口是巨大的,那么它是巨大的,做你自己的算术.

9. 您还需要一个表,Property(或属性)的查找表.这是目录的一部分,并基于ProductType

更好的解决方案是获得完整,正式的第六范式.如果只有一个或几个表需要可选列,则不需要.

要明确:

• 第六范式是The Row由主键和最多一个属性组成.

• 这是6NF(至少对于Product表集群),然后通过DataType再次标准化(不是在Normal Form意义上),以减少表的数量(否则每个Attribute将有一个表).

• 这保留了完整的Rdb控制(FK,约束等); 而常见的EAV类型不需要DRI和控制.

• 这也有目录的雏形.

链接到产品群集数据模型

链接到IDEF1X表示法,适用于那些不熟悉关系建模标准的人.

更新

您可能对此感兴趣吗？5NF 6NF讨论？.我会在某个时候写出来的.