2

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

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

实现这一目标的一种方法是： 一对多关系

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

另一方面，我们可以创建这样的东西： 多对多关系

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

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

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

谢谢你。

4

3 回答 3

1

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

  • 客户 ：id | name

  • 客户地址：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

于 2013-11-08T17:22:37.130 回答
0

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

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

于 2013-11-08T17:10:44.383 回答
0

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

于 2013-11-08T17:11:55.447 回答