数据库设计：定义数据库中实体之间的关系

Question

我想为我的应用程序设计一个数据库，但我对如何定义实体之间的关系有疑问。

我有 2 个相关实体，其 ID 是复合的。例如：

• 由属性[街道号码、门牌号码、城市、国家/地区]和电话号码（xx-yyyyyy）标识的地址实体
• 由属性 [区域编号，编号] 标识的实体。

关系是“每个地址有几个电话号码。我有两种可能的方式来定义表格：

1. 由所有 ID 字段连接的表
   • 地址→[街道号码、门牌号码、城市、国家、...、地区号码、号码]
   • PhoneNumber → [地区号码，号码，...]
2. 具有由该字段连接的 ID 字段 (GUID) 的表。
   • 地址 → [ID、门牌号、门牌号、城市、国家、...]
   • PhoneNumber → [ID、地区号码、号码、...、AddressID]

在第一种解决方案中，主键将是标识实体的所有字段，而在第二种解决方案中，主键将仅是ID字段。

我的问题是 - 更好的方法是什么？ （按性能、维护、设计等...）

Answer 1

无论您是否有 GUID，第二个选项更易于编码和设计。当您通过连接两个表来选择数据时，您只需要索引标识符列。 另一种方式，您需要复合索引来进行此连接。

根据我的经验，在企业公司系统的表中拥有唯一的主键是一种宝贵的做法。 （从 dba 和开发人员的角度来看）

为性能设计数据库是一个涉及许多标准的复杂问题。如果您手头有 Oracle，请在实践中使用您的两种方法并使用解释计划工具，而不是追求理论。我的意思是使用您提到的方法创建表，使用索引并使用解释计划。如果我没记错的话，Oracle 甚至可以通过投影（即通过让您估计表中的行数）为您提供有关查询性能的想法。我不确定 Express Edition 版本是否支持此功能

Answer 2

主键永远不会是“表中的所有字段”。这不是关系数据库应该如何工作的，所以忘记这种方法。

键就是键，数据就是数据。永远不要把两者混为一谈。如果混合使用它们，最终会出现这样一种情况，即您需要在数据更改时立即更改密钥和数据库中使用它的所有记录。哪个不好。

设计这种（常见的）1:n 关系的唯一正确方法是：

地址电话号码 -------- ----------- *ID

* 表示主键，通常是一个带有唯一索引的自动递增数字。

箭头表示外键关系。