时间戳

首页 > 解决方案 > 如何确保产品规格适用于类别实体？

mysql - 如何确保产品规格适用于类别实体？

问题描述

我有下表：

  1. 产品（id、名称、价格、category_id）
  2. 类别（ID、名称、描述）

现在因为每个类别的产品可能与其他类别的产品具有不同的属性，所以我想使用EVA，但这是我的问题：

我想确保添加的任何产品属性值都属于该产品的类别，并且不允许添加不属于它的属性。

你能告诉我怎么做吗？

标签： mysqlsqlrelational-databaseentity-relationshiprdbms

解决方案

我想确保添加的任何产品属性值都属于该产品的类别，并且不允许添加不属于它的属性。你能告诉我怎么做吗？

当然。在建模和 SQL 级别，这是一个相当普遍的要求，而且非常直接。然而，由于“理论家”将原始 1960 年代的记录归档系统推广为“关系”，以及同一群人对关系方法的压制，因此不得而知。

RFS 是物理的（Record IDs链接记录，而不是行），而关系模型是逻辑的，使用逻辑键，链接行而不是记录。并且关系键提供了意义。所以首先需要理解这个概念，然后实现起来很容易。

1960 年代唱片归档系统

您的文件：

RFS

关系数据库 • 概念 • 子类型

这是您需要了解的概念。

概念

  • 根据您的要求，每个类别都需要产品中的不同属性，并且每个类别都相互排斥。
  • 它是一个普通的 Subtype 集群，在这种情况下是 Exclusive。
  • 有些人可能称其为“元数据”，因为它超越了数据，并且对产品具有决定性的影响。
  • 有关子类型的更多信息。

1960 年的记录归档系统 • 实施

现在使用给定的文件来实现。

要求

  • 将 Category 维护为逻辑键（CHAR键，充满意义，而不是 a Record Id）。
  • 我们在 Product 中部署 Exclusive Subtype 集群，以 Category 作为 Discriminator。
  • 但是，由于使用Record IDs, 哪些是物理键，哪些不是逻辑键，而是实现为PRIMARY KEY，这会让任何人感到困惑，因此 Product 文件中的行可以重复
    • 每个逻辑产品行都必须是唯一的
    • 这意味着，根据 EF Codd 博士的关系模型，使用“由数据组成”的密钥
    • 产品Name是PK的唯一可能性

关系数据库 • 实施

如果我们将系统提升到关系，并防止行的重复（而不是记录），这是被禁止的：

执行

  • 人类用户不会使用数字作为标识符。他们ProductId没有看到或使用它们。
  • 这Name是唯一唯一的行（产品）标识符，但是它太长而不能被指定为主键。尽管如此，它必须是唯一的。
  • 用户将使用短代码作为产品标识符。
  • 这使得ProductId非常无用和冗余（一个额外的列和一个额外的索引）。
  • 像往常一样，这也是最少的列和索引。

SQL

以上都是普通的 SQL，关系模型的数据子语言。它可以使用普通 SQLCONSTRAINTs等以完全保护和完整性来实现。子类型文档提供了完整的实现细节。

  • 但是请注意，MySQL 和 PusGreSQL不是 SQL（它们不符合 SQL 要求，并且缺少 SQL 的许多普通功能），因此它们对术语的使用SQL是欺诈性的。
  • 此外，它们没有服务器架构，这意味着性能很糟糕，并发性很差。

推荐阅读