这些数据库设计样式（或反模式）是否具有名称？

Question

考虑一个包含表Products和Employees的数据库。对当前产品经理进行建模是一项新要求，他是负责产品的唯一员工，并指出某些产品简单或成熟，不需要产品经理。也就是说，每个产品可以有零个或一个产品经理。

方法1：更改表Product以添加新的NULL能列product_manager_employee_ID，以便没有产品经理的产品由NULL值建模。

方法2：使用非ProductManagers列NULL和product_ID创建一个新表employee_ID，并在product_ID上设置唯一约束，以便没有产品经理的产品是通过此表中没有一行来建模的。

还有其他方法，但这些是我最常遇到的两种方法。

假设这些都是合法的设计选择（我倾向于相信）并且只代表不同的风格，他们有名字吗？我更喜欢方法2并且发现很难将风格差异传达给那些喜欢方法1而没有使用实际例子的人（正如我在这里所做的那样！）如果我能说“我更喜欢我自己倾向于6NF（或其他）风格。“

假设其中一种方法实际上是一种反模式（因为我只是怀疑方法1的情况可能是通过将两个实体之间的关系建模为这些实体之一的属性），这种反模式是否具有命名

Answer 1

首先，这只不过是一对多的关系（一个员工对很多产品）。这有时被称为O：M关系（零到多），因为它是可选的（并非每个产品都有产品经理）。同样不是每个员工都是产品经理，所以另一方也是可选的。

第二个是连接表，通常用于多对多关系。但由于一方只是一对一（每个产品只在表中一次），它实际上只是一个错综复杂的一对多关系。

就我个人而言，我更喜欢第一种，但两种都不错（或不好）。

第二种用法会出现两个原因。

1. 您设想产品可能有多个经理;或
2. 您想要跟踪产品经理的产品历史记录。你这样做，比如说current_flag列设置为'Y'（或类似），其中一次只能有一个当前。在以数据库为中心的应用程序中，这实际上是一种非常常见的模式。

Answer 2

在我看来，这两种模式的不同行为。在第一个示例中，每个产品可以有一个产品经理，一个员工可以是多个产品（一个到多个）的产品经理。第二种似乎允许每个产品（多对多）产品经理不止一个。这表明两种解决方案在不同情况下同样有效，您使用哪种解决方案取决于业务规则。

Answer 3

第一种方法存在缺陷。想象一下，业务需求已经改变，现在您需要能够将2个产品经理设置为产品。你会怎么做？在表Product中添加另一列？呸。这显然违反了1NF。

第二种方法提供的另一种选择是能够存储某个产品经理的某些属性＆lt; - ＆gt;产品关系。比如，如果您有一个产品的两个产品经理，那么您可以将其中一个设置为主要... 或者，例如，员工可以拥有一个电话号码，但作为产品经理，他/她可以拥有另一个电话号码......这也会转到特殊表格。

Answer 4

方法1）

1. 使用附加的产品经理字段减慢Product表的使用（可能不适用于所有数据库，但对于某些数据库）。
2. 从Product表链接到Employee表非常简单。

方法2）

1. 使用Product表的现有查询不受影响。
2. 增加数据库的大小。您现在已将Product ID列复制到另一个表，并为该表添加了唯一约束和索引。
3. 从Product表到Employee表的链接更加繁琐和昂贵，因为您必须先向中间表着墨。

您必须经常在两个表之间建立链接吗？

有多少其他查询使用Product表？

Product表中有多少条记录？

Answer 5

在你给出的特定情况下，我认为两个表的主要动机是避免缺失数据的空值，这就是我如何表征这两种方法。

讨论了利弊on wikipedia。

我很确定，鉴于c date不喜欢这个，他定义了关系理论，以便只有多表解决方案是“有效的”。例如，您可以将单表方法称为“输入不良”（因为null的类型为unclear - 请参阅第4页的引用）。