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

我正在尝试设计一个新的数据库结构，并且想知道在下面的示例中使用表之间的一对多关系和多对多关系有什么优点/缺点

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

实现这一目标的一个方法是：

这是一种相当直截了当的方法，其中每个关系都是一对多类型的，但需要为每个地址类型创建额外的表

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

这一次，我们只需存储一个额外的“type”字段，指示地址的类型（客户账单（0）、客户发货（1）、产品联系人（2））和“source_id”，即（Clients.id或Products.id，取决于“type”字段的值）

这样，“地址”表就没有到任何其他表的“直接”链接，但其结构似乎要简单得多

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

---

谢谢。

底部型号的问题是，当帐单和发货地址相同时，您将最终存储冗余数据

---

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

我认为您自己已经大致涵盖了答案。 对我来说，这真的取决于你在做什么建模，以及你认为它在未来会发生什么变化。 就个人而言，我不推荐工程解决方案，所以一对多解决方案听起来很棒。 但是，如果您预计您的需求将在一个月内发生变化，那么请选择多对多。 这才是你真正需要的。 您可以在稍后阶段更改数据库，使其具有多对多关系，但会产生成本和时间影响。 就个人而言，我会根据需要保持数据库结构的简单性，但我会理解以后如何更改它。 就我个人而言，我只使用了MS-SQL Server，所以也许其他人对其他数据库技术有更好的了解。 我想看看您使用什么来访问数据库会很有趣，例如存储过程，或者类似NHibernate或实体框架的东西。 如果你认为改变数据库结构会给你带来大问题（对我来说总是这样），那就试试看你是如何做到的。

---

这将为您提供做出更明智决策所需的经验。

这两种设计中似乎都存在冗余，使用带有“地址类型”字段的连接表以及跨所有三列的唯一约束将最小化这一点

• 客户：

  id| name

• 客户地址：

  客户id |地址id |地址类型

• 地址：

  id |一行|二行|三行|四行|五行

• 产品地址：

  产品标识|地址标识|地址类型

• 产品：

  id |名称

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

• 客户：

  id |姓名|账单|地址|联系人|地址

• 地址：

  id |一行|二行|三行|四行|五行

• 产品：

  id |姓名|账单|地址|联系人|地址

---

在这两个选项中，我喜欢第一个，因为它更规范化。未来的挑战包括处理地址更改。感谢您的投入。第一种方法看起来很有希望。我会考虑的。但是，您的第二种方法不适合我，因为在我的情况下，一个客户可能有许多联系地址。