8

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

方法一：alter tableProduct添加一个新的NULLable 列product_manager_employee_ID，这样一个没有产品经理的产品就可以通过这个NULL值来建模。

方法 2：创建一个新表ProductManagers，其中包含不可NULL列的列，product_ID并且employee_ID对 具有唯一约束product_ID，因此没有产品经理的产品通过该表中缺少行来建模。

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

假设这些都是合法的设计选择（我倾向于相信）并且仅仅代表不同的风格，他们有名字吗？我更喜欢方法 2，并且发现很难在不使用实际示例的情况下向喜欢方法 1 的人传达风格上的差异（就像我在这里所做的那样！）如果我可以说，“我更喜欢倾向6NF（或其他）风格我自己。”

假设其中一种方法实际上是一种反模式（我只是怀疑方法 1 可能是通过将两个实体之间的关系建模为其中一个实体的属性）这种反模式有名称吗？

4

5 回答 5

9

那么第一个只不过是一对多的关系（一个员工对许多产品）。这有时被称为 O:M 关系（零对多），因为它是可选的（并非每个产品都有产品经理）。也不是每个员工都是产品经理，所以另一方面也是可选的。

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

就我个人而言，我更喜欢第一个，但两者都不是错误的（或坏的）。

第二个将用于我想到的两个原因。

  1. 您设想一种产品可能会有多个经理；或者
  2. 您想跟踪产品经理是谁的历史。您可以使用设置为“Y”（或类似）的 current_flag 列来执行此操作，其中一次只能有一个是当前的。这实际上是以数据库为中心的应用程序中非常常见的模式。
于 2009-06-05T09:25:27.627 回答
2

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

于 2009-06-05T09:26:35.597 回答
0

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

第二种方法提供的另一个选项是能够为某个 Product Manager <-> Product 关系存储一些属性。就像，如果您有两个产品经理，那么您可以将其中一个设置为主...或者，例如，员工可以有一个电话号码，但作为产品经理，他/她可以有另一个电话号码... 然后这也转到特殊表。

于 2009-06-05T09:30:39.410 回答
0

方法 1)

  1. 使用附加的 Product Manager 字段减慢 Product 表的使用速度（可能不是针对所有数据库，而是针对某些数据库）。
  2. 从 Product 表链接到 Employee 表很简单。

方法2）

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

您必须多久在两个表之间链接一次？

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

Product 表中有多少条记录？

于 2009-06-05T18:52:52.323 回答
0

在您给出的特定情况下，我认为两个表的主要动机是避免丢失数据的空值，这就是我描述这两种方法的方式。

维基百科上有一个关于利弊的讨论。

我很确定，鉴于 c date 不喜欢这一点，他定义了关系理论，因此只有多表解决方案是“有效的”。例如，您可以将单表方法称为“类型不佳”（因为 null 的类型不清楚- 请参阅 p4 上的引用）。

于 2012-03-26T11:59:08.213 回答