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 回答