首页 > 解决方案 > 单表与两个一对一相关表的性能

问题描述

假设我们要在关系数据库中存储以下数据:CountryName, CapitalCityName, CapitalCityPostCode. 让我们假设一个城市只有一个邮政编码。我们可以用一种简单的方式在一个表中实现它:

Countries
[PK]CountryId, CountryName, CapitalCityName, CapitalCityPostCode

或者我们可以以更规范的方式将其以 1:1 的关系排列成 2 个表:

 Coutries  
 [PK]CountryId, CountryName, [FK]CapitalCityId

 CapitalCities
 [PK]CapitalCityId, CapitalCityName, CapitalCityPostCode, [FK]CountryId

这将如何影响性能?例如 - 如果我们需要列出所有国家的首都名称,在第一种情况下会明显更快吗?我需要多少记录/列才能看到差异?

标签: sqldatabasedatabase-designrelational-database

解决方案


显然你可以看到第一不是第三范式。在性能方面,即使在处理 10 和 100 条记录时,正确规范化的表也将与第一个示例中的平面表相当。虽然平面文件总是会稍微快一点,但如果相关得当,数量会微不足道。第一个问题随着时间的推移变成可伸缩性。如果需要增长,您将放弃轻微的性能提升以获得不稳定的基础

充其量只是一个边际差异。单桌总会有微弱优势;当您处理数亿条记录时,这会变得更加明显+。但是可以通过将表划分为相关块来解决这个问题,这样引擎就可以多线程收集结果并根据连接和过滤条件消除大量不需要的记录。

与任何其他开发一样,没有单一的灵丹妙药。规则总是有例外的;每个问题的背景都很重要。然而,粗略的方法说,除非你知道永远不会增长,否则正常化。(永远不会很长!但也许系统有一个已知的保质期,并且永远不会实现如此长期的存在。)


推荐阅读