表上的主键定义

Question

与我的一位同事进行了一次小小的辩论，他们负责在我们的一个软件产品中设计一些表格。

我的同事建议使用这样的结构，我将表格简化为几列直接指向：

Table Buildings

Columns: buildingId,address,zipcode, ...
PK: buildingId

Table Offices

Columns: buildingId, officeId, officeName, ...
PK: buildingId, officeId

Table Workers

Columns: buildingId, OfficeId, workerId, name, surname
PK: buildingId, OfficeId, workerId

根据定义＆＃34;选择＆＃34;要使用代理键，例如buildingId，OfficeId和workingId，我告诉我的观点是：

1. 第一张桌子的PK对我来说没问题
2. 第二个表的PK为officeId，buildingId为FK
3. 第三个表格的PK为workerId，officeId为FK，我将完全省略BuildingId，因为这是多余的。

所以结果将是这样的：

Table Buildings

Columns: buildingId,address,zipcode, ...
PK: buildingId

Table Offices

Columns: buildingId, officeId, officeName, ...
PK: officeId
FK: buildingId

Table Workers

Columns: officeId, workerId, name, surname
PK: workerId
FK: officeId

我的同事告诉我，按照他的建议选择PK更自然，使用这些PK查询这些表格的表现会更好，父/子关系也会更清楚

例如，他告诉我，在他的模型中使用officeId和buildingId查询工具的查询将比仅使用officeId更快。

在我看来，在表中使用buildingId是非规范化的，并且可能在将来导致问题（例如，丢失数据完整性时出现更新错误，以非正确的方式更新buildingId表工人）。

我认为正确使用索引是在这种情况下提高性能的正确方法，而不是声明父表PK＆＃34;作为儿童表的一部分＆＃34;的PK。我也认为＆＃34;父母/孩子＆＃34;关系是比RDBMS更分层的DBMS。

有什么建议吗？