建模数据库:是否有许多小表?

听起来,有问题的“信息”是组成键值的数据。如果是这样,听起来数据库设计者喜欢使用自然键,而您更喜欢使用代理键。

首先,这两者都只是一个风格问题。如果自然键值是复合的(即涉及多个列),并且出于数据完整性的目的包含在其他列中,则它们不是冗余的。

第二,正如您所观察到的,当谈到代理键的性能时,您必须权衡更高效的数据类型(例如,单个整数列)的优势与需要写入更多联接的性能下降之间的关系。请注意,使用代理往往会使约束的编写更麻烦,例如,当规则的必需值位于另一个表中,并且您的SQL产品不支持检查约束中的子查询时,您将需要使用触发器,这会降低高活动环境中的性能。

进一步考虑性能不是唯一的考虑因素,例如,使用自然键值将倾向于使数据更具可读性,从而使模式更易于维护,因为物理模型将更紧密地反映逻辑模型(代理键根本不出现在逻辑模型中)。

Normalisation . 与许多设计方面一样,这是一种权衡。

在数据库中存在重复会导致许多问题—例如,如何在更新数据时保持这些重复的同步。因此,插入和更新可能会更慢 重复的部分。因此,我们倾向于规范化数据库,以避免这种重复。这确实会导致更复杂的查询和可能的检索开销。

现代的数据库产品往往能够很好地完成这类查询,如果您注意使用适当的索引的话。

因此,我的出发点是使数据正常化,避免重复。然后在一个特殊的情况下,也许反规范化只是一些真正必要的部分。例如,假设数据库的某个部分很大,大部分是查询的而不是更新的(例如历史订单信息),那么可能会对该部分进行反规范化。

这不是风格问题。

现在一个整数FK可能是“整洁的”,但是任何好的、短的、固定长度的键都可以。可变长度的键对性能非常不利,因为每次搜索索引时都需要对键进行解包。

只要你在键上连接,连接本身就不需要任何费用;构造一行的十个连接花费不超过五个。成本以表格大小为单位;使用的指数;分配;索引列的数据类型;关系数据库管理系统是为规范化数据库设计的。

如果你需要做一次又一次的查找,那么就是这样。只要确保桌子正常。

如果你不正常化

• 如何将“Lookup value”和“Lookup value”等分开