使用一对多与多对多关系的数据库设计优势答案

【问题标题】：Database design advantages for using one-to-many vs many-to-many relationships使用一对多与多对多关系的数据库设计优势
【发布时间】：2013-11-20 18:50:45
【问题描述】：

我正在尝试设计一个新的数据库结构，并且想知道在以下示例中使用表之间的一对多与多对多关系的任何优点/缺点。

假设我们需要存储有关客户、产品及其地址的信息（每个客户和产品可能有许多不同的地址（例如“运输”和“帐单”）。

实现此目的的一种方法是：

这是一种相当直接的方法，其中每个关系都是一对多类型，但涉及为每种地址类型创建额外的表。

另一方面，我们可以创建如下内容：

这一次我们简单地存储一个额外的“类型”字段来指示它是什么类型的地址（Client-Billing (0)、Client-Shipping (1)、Product-Contact (2)）和“source_id” （Clients.ID 或 Products.ID 取决于“type”字段的值）。

这种方式“地址”表没有指向任何其他表的“直接”链接，但结构似乎要简单得多。

我的问题是，这两种方法中的任何一种是否有任何显着优势，还是只是偏好问题？你会选哪一个？将来扩展数据库时我应该注意哪些挑战？是否存在显着的性能差异？

谢谢。

【问题讨论】：

这两个中，我喜欢第一个，因为它更加规范化。未来的挑战包括处理地址更改。

标签： sql database foreign-keys schema

【解决方案1】：

这两种设计似乎都存在冗余，使用具有“地址类型”字段的联结表和跨所有三列的唯一约束可以最大限度地减少这种情况。

客户：id | name
client_address : client_id | address_id | address_type
地址：id | line_one | line_two | line_three | line_four | line_five
产品地址：product_id | address_id | address_type
产品：id | name

或者使地址类型成为产品和客户的属性

客户：id | name | billing_address | contact_address
地址：id | line_one | line_two | line_three | line_four | line_five
产品：id | name | billing_address | contact_address

【讨论】：

感谢您的意见。第一种方法看起来很有前途。我会考虑一下。但是，您的第二种方法不适合我，因为在我的情况下，一个客户可能有很多联系人地址。

【解决方案2】：

我认为您自己已经回答了很多问题。对我来说，这真的取决于你在建模什么，以及你认为它在未来会如何变化。我个人不推荐工程解决方案，所以一对多的解决方案听起来很棒。但是，如果您预计您的需求会在 1 个月内发生变化，请选择多对多。这真的是你需要的。您可以在稍后阶段更改数据库以建立多对多关系，但会产生成本和时间影响。就我个人而言，我会根据需要保持数据库结构尽可能简单，但是要了解以后如何更改它。我个人只用过MS-SQL Server，所以也许其他人对其他数据库技术有更好的了解。我认为看看你使用什么来访问你的数据库会很有趣，例如 Sprocs，或者像 NHibernate 或 Entity Framework 之类的东西。如果您认为更改数据库结构可能会给您带来大问题（对我来说总是如此），请尝试并找出您将如何做到这一点。这将为您提供做出更明智决策所需的经验。

【讨论】：

【解决方案3】：

底部模型的问题是，当帐单地址和送货地址相同时，您最终会存储冗余数据。

您可以保留底部模型中的关联表，但从中删除实际地址字段并将它们放在自己的表中，这样您就不会多次存储地址，仍然是规范化的，但表会减少 2 个。

【讨论】：