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

Question

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

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

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

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

1. 通过所有ID字段连接的表
   • 地址→[街道号码，门牌号码，城市，国家，......，地区号码，号码]
   • 电话号码→[地区号码，号码，......]
2. 具有通过此字段连接的ID字段（GUID）的表。
   • 地址→[ID，街道号码，门牌号码，城市，国家，......]，
   • 电话号码→[ID，地区号码，号码，......，地址ID]

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

我的问题是 - 更好的方法是什么？ （通过表演，维护，设计等......）

Answer 1

您是否拥有 G UID第二个选项更容易编码和设计。通过连接两个表来选择数据时，您只需要索引标识符列。 另一种方法是只需要这个连接的复合索引。

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

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

Answer 2

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

密钥是密钥，数据是数据。永远不要混淆两者。如果混合它们，最终会出现这样的情况：一旦数据发生变化，您需要更改密钥以及数据库中使用它的所有记录。这很糟糕。

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

Address               PhoneNumber
-------               -----------
 *ID         <---+     *ID
 StreetNumber    +---  AddressID
 HouseNumber           RegionNumber
 City                  TheNumber
 Country               ...
 ...

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

箭头表示外键关系。