数据库的第3范式是否正常？

Question

在设计数据库时，我是否应始终瞄准第4范式？

我觉得第3范式更接近我的业务领域。

例如，我有一张PartNumber的表格。在我的业务领域，它是唯一的密钥，没有两个部分具有相同的编号。但是这是一个VARCHAR，将一个主键放到VARCHAR上，然后将它作为外键链接到其他表对我来说是一个巨大的气味。

我应该在任何地方添加自动增量ID吗？我并没有立即明白这一点，它使代码复杂化了很多。

Answer 1

作为一般规则，目标是使您的数据库至少处于Boyce-Codd Normal Form或理想的Fifth Normal Form。只考虑存在依赖性的3NF，保留5NF无法满足的依赖性。

4NF与您在密钥中使用varchar或整数无关，我不确定您为什么认为它会这样做。

Answer 2

这取决于数据库;使用varchar字段作为PK会浪费数据库存储空间和MySQL中的索引（例如）。为您的零件编号提供一个表格和唯一的整数id可能看起来不那么纯粹，但这些事情有时在性能方面是必要的。

（此外，它确实允许您在必要时在一个位置更新产品编号，但我怀疑在您的业务逻辑中可能不太可能。）

Answer 3

虽然您的问题询问4NF，但您的具体情况并非如此。使用VARCHAR字段作为主键不是错误，如果它相对较小，那么我宁愿使用它而不是代理键。

回到4NF - 来自Wikipedia's example，这似乎是在很多时候，自然而然地落实到位的东西。争取4NF肯定不会受到伤害 - 同时非规范化也有其地位。

Answer 4

您是否允许用户编辑部件号？如果是这样，这是反对使用它作为主键的一个很好的论据。作为（一般）经验法则，PK不应该是用户可编辑的，因为通过DB复制更改的PK会变得非常昂贵。

此外 - 没有两个部件具有相同的编号，或者没有两个活动部件可以具有相同的编号？如果是后者，您是否需要保留足够长的历史记录，最终可能会得到两个相同的部件号？

Answer 5

学习如何规范化数据需要几周时间。要花几个月甚至几年的时间来学习何时忽视规范化规则。当然，如果你无视规范化规则，就会产生后果。如果你彻底学会了规范化，你就会知道后果。

与遵循其他设计模式的好处相比，有时不遵守给定的正常形式的后果是轻微的。例如，在构建OLAP数据库或数据仓库时，星型模式或雪花模式通常比完全规范化更高效。

对于OLTP数据库，我倾向于以Boyce-Codd的正常形式为目标，并且只处理由于偏离第4或第5范式而出现的任何修改异常。但这实际上取决于案例。