database-design - 数据库模式相关问题

Question

我有一个关于数据库的理论问题。为了使它更具体，我想出了一个示例案例。

假设我有一家产品商店。我有很多不同的产品。并非每种产品都具有相同的适用特性。例如，我可以以 GB 为单位定义硬盘的大小，但不能在 CPU 上使用相同的属性，因为它不适用。我想要的是一个数据库，我可以在其中动态地向产品添加属性。我唯一能想到的是:

一个带有 ID、名称和描述的产品表。

一个带有 ID、Product_ID、Property 和 Value 的属性表。

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

Answer 1

这实际上是在走向第六范式，只是像你这样没有学术或经验背景的人不知道(a)它的名称和(b)规则和警告。这些人已经实现了众所周知的实体-属性-值或 EAV。如果操作得当，那就没问题了，并且有成千上万的医疗系统在这些表格中携带诊断和剂量信息。如果不是，那么使用和维护是一只狗的早餐。

首先确保你有 Product在真正和完整的 5NF。

始终使用完整的声明式引用完整性； CHECK约束和 RULES .

永远不要把所有的东西都放在一张 table 上 VARCHAR()为值(value)。始终使用正确(适用)的数据类型。这意味着您将拥有多个表，每个数据类型一个，并且不会丢失控制或完整性。

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

我提供了一个数据模型，其中讨论了完全控制；它包括一个简单的目录，可用于验证和导航。您需要添加每个 CHECK约束和 RULE以确保数据和引用完整性不会丢失。这意味着，例如:

为 CPUSpeed列，存储在 ProductDecimal , CHECK它在适当的值范围内

对于每个子 Product表CHECK数据类型对于 ProductType-ColumnNo 是正确的组合

这种结构比大多数 EAV 好得多，而不是完整的 6NF。
.

将所有必填列保留在 Product 中;使用 sub-Product仅用于可选列的表。

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

不要通过 View 更新。将所有更新保持在事务性的存储过程中，并将每个列(即适用于每个特定 Product 的 sub-Product 和 ProductType 表)一起插入或更新。

巨大的？商业数据库(不是免费软件)在处理大表或连接时没有问题。这实际上是一个非常有效的结构，并且允许非常快速的搜索，因为表实际上是面向列的(而不是面向行的)。如果人口是巨大的，那么它是巨大的，做你自己的算术。

您还需要一张表，即 Property 的查找表。 (或属性)。这是目录的一部分，基于 ProductType

更好的解决方案是采用完整、正式的第六范式。如果您只有一张或几张需要可选列的表，则不需要。

要清楚:

第六范式是 行由主键和最多一个属性组成。

这是 6NF(至少对于 Product 表集群)，然后通过 DataType 再次规范化(不是正常形式意义上的)，以减少表的数量(否则每个属性将有一个表)。

这保留了完整的 Rdb 控制(FK、约束等)；而常见的 EAV 类型不需要 DRI 和控制。

这也有目录的雏形。

Link to Product Cluster Data Model

Link to IDEF1X Notation 对于那些不熟悉关系建模标准的人。

更新

您可能对此感兴趣 ▶5NF 6NF Discussion◀ .我会在某个时候写下来。