我学习关系设计已经有很长时间了，但我有一个模糊的记忆，它鼓励不要不必要地拆分表。例如，给定函数依赖
K -> A
K -> B
K -> C
我的假设是，“最佳”模式是公正的{KABC}，而不是类似{KAB, KC}或什至{KA, KB, KC}. 至少在实践中，这是我看到数据库设计人员实现该表的方式。
然而，维基百科上的快速复习表明规范化形式主义
- 没有在获得“最小模式”的方向上发表任何声明，
- 6NF 甚至需要
{KA, KB, KC}. 由于 6NF 暗示了其他范式，这意味着它们甚至不可能做出这样的最小要求。
我有点困惑，我一直都错了。“获得最少数量的表”的概念在正式的关系设计中真的没有任何作用吗，它只是一种常见的做法？
“Normal Forms”被狭义地定义为消除冗余数据和“更新异常”。修复其他模式设计问题是否算作“规范化”可能存在争议，但一般来说，规范化只是意味着确保数据库符合某种规范形式。
无论是在设计理论中还是在实践中，减少表的数量都不是目标。减少表可以帮助或损害性能，这就是为什么人们在实践中增加或减少表（不管重复数据）。
粗略地说，当你有很少结合使用的数据时，增加表的数量是有帮助的，当你有经常结合使用的数据时，减少表的数量是有帮助的。关系理论并不关心某事有多快或多慢。理论让你不会陷入无效状态，实际上，一些无效状态可能是可以接受的，只要最后一切顺利。
为了增加关于规范化的其他答案，除了关于如何构建数据库来表示数据的理论之外，可能会有一些实际考虑因素可能使拆分表变得明智。
例如，您可以在 Postgres 中找到一种可能的 ACID 实现，包括在更新时删除并重新插入一行，然后通过清理来回收已删除的行。因此，如果您的表可能包含大量主要读取的数据和用于标记行以进行处理的脏位，则将脏位拆分到单独的表中可以显着提高性能，因为 UPDATE 需要重写一小部分数据。它还可以为您节省大量磁盘空间，因为单表情况会不断重复数据，直到 VACUUM 可以回收死元组。
当部分数据太大以至于被 TOASTed 时，可能会出现类似的问题，因此您可能希望将经常访问或更新的字段拆分到单独的表中。