这些数据库设计风格(或反模式)有名称吗？
考虑一个包含表Products和Employees的数据库。有了一个新的需求来模拟当前的产品经理，成为负责产品的唯一员工，注意到一些产品足够简单或足够成熟，不需要产品经理。也就是说，每个产品可以有零个或一个产品经理。
方法1: alter table Product以添加一个新的支持NULL的列product_manager_employee_ID，以便由NULL值对没有产品经理的产品进行建模。
方法2:创建一个新的表ProductManagers，其中包含不支持NULL的列product_ID和employee_ID，并对product_ID进行唯一约束，以便通过该表中缺少一行对没有产品经理的产品进行建模。
还有其他方法，但这是我最常遇到的两种方法。
假设它们都是合法的设计选择(正如我倾向于相信的那样)，只是代表了不同的风格，它们有名字吗？我更喜欢方法2，并且发现很难将风格上的差异传达给那些更喜欢方法1而不使用实际示例的人(就像我在这里所做的那样！)如果我能说：“我自己更喜欢倾向于-6NF(或其他)风格，我会很高兴的。”
假设这些方法中的一个实际上是反模式(我只是怀疑方法1可能是这种情况，通过将两个实体之间的关系建模为其中一个实体的属性)，这个反模式有名称吗？
回答 5
Stack Overflow用户
发布于 2009-06-05 09:25:28
首先是一对多的关系(一个员工对应多个产品)。这有时被称为O:M关系(零对多)，因为它是可选的(并不是每个产品都有产品经理)。此外，并不是每个员工都是产品经理，所以在另一方面也是可选的。
第二个是连接表，通常用于多对多关系。但由于只有一方是一对一的(每个产品只在表中出现一次)，这实际上只是一个复杂的一对多关系。
就我个人而言，我更喜欢第一个，但这两个都不是错的(或坏的)。
使用第二种方法的原因有两个。
- 你可以想象一个产品有多个经理的可能性；或者
- 你想要跟踪产品经理是谁的历史。你可以这样做，比如一个current_flag列设置为'Y‘(或类似的)，一次只能有一个是当前的。这实际上是以数据库为中心的应用程序中非常常见的模式。
Stack Overflow用户
发布于 2009-06-05 09:26:36
在我看来，这两个模型的行为是不同的。在第一个示例中，每个产品可以有一个产品经理，一个员工可以担任多个产品的产品经理(一对多)。第二种方式似乎允许每个产品有多个产品经理(多对多)。这表明这两种解决方案在不同的情况下同样有效，您使用哪种解决方案取决于业务规则。
Stack Overflow用户
发布于 2009-06-05 09:30:39
第一种方法有一个缺陷。想象一下，业务需求发生了变化，现在您需要能够将2个product Manager设置为一个产品。你会怎么做？是否向表Product中添加另一列？糟透了。这显然违反了1NF。
第二种方法提供的另一个选项是存储特定Product Manager <-> Product relation的某些属性的能力。例如，如果一个产品有两个产品经理，那么您可以将其中一个设置为主要...或者，例如，员工可以有一个电话号码，但作为产品经理，他/她可以有另一个电话号码……这也适用于特殊的表格。
https://stackoverflow.com/questions/954988
复制相似问题
腾讯云开发者
