sql - 您如何知道 SQL 数据库何时需要更多规范化？

Question

是在您尝试获取数据并且没有明显的简单方法时吗？

当你发现某个东西应该是一张自己的桌子？

有哪些法律规定？

score 7 · Accepted Answer

查看维基百科。这篇文章讨论了数据库规范化和不同的形式（第一、第二、第三等）。大多数时候，您应该至少以第三范式为目标。有时您想稍微放宽规则（将多个表连接在一起可能太昂贵，因此可能需要进行一些反规范化），但在大多数情况下，第三范式是好的。

score 6 · Accepted Answer

当您注意到您必须重复相同的数据时，或者当您开始使用单个字段作为数组时。

score 3 · Accepted Answer

虽然这是一个有点刻薄的答案，但当您发现数据没有充分标准化时。网络上有很多关于规范化级别（或者更准确地说是“形式”）的资源，它们比我在这里更完整地描述了这些形式。应该非常需要第一和第二范式。如果你不是第三（或者，实际上，第四）范式，你需要有一个强有力的理由来解释为什么。

score 2 · Accepted Answer

只要你有一个关系数据库......<grin/>

不，实际上有法律，请查看此 Wikipedia链接。

它们被称为五种范式或类似的东西。最初来自于 50 年代/60 年代发明关系数据库的人 EF Codd。

“钥匙就是钥匙，只有钥匙，所以帮我科德”

这是一个概要：

第一范式 (1NF) 表忠实地表示关系并且没有重复组
第二范式 (2NF) 表中没有非主属性在功能上依赖于候选键的一部分（正确子集）
第三范式 (3NF) 每个非素数属性都非传递地依赖于表的每个键表中的每个非平凡函数依赖都是对超键的依赖
第四范式 (4NF) 表中的每个非平凡多值依赖项都是对超键的依赖项
第五范式 (5NF) 表中的每个非平凡连接依赖项都由表的超键隐含。域/键范式 (DKNF) Ronald Fagin (1981)[19] 表上的每个约束都是表的域约束和键约束的逻辑结果
第六范式（6NF）表完全没有非平凡的连接依赖关系（参考广义连接运算符）

score 2 · Accepted Answer

Other people have pointed you to the formal rules for normalization. Here are some informal guidelines I use:

If you have columns in a table the names of which differ only by a number (eg Phone1 and PHone2).
If you have any columns in a table that should be filled in only when another column in the table is filled in.
If updating a "fact" in the database (such as a street address) requires more than one UPDATE.
If the same question could ever get two different answers depending on which table you get your information from.
If the answer to any non-trivial question can be gotten from the database without JOINing at least two tables.
If you have any quantity-based restrictions in the database other than "only 1 of something is allowed" (that is, "only one address is allowed" is okay, but "only two addresses are allowed" indicates a normalization problem).

score 2 · Accepted Answer

2

当您开始质疑 SQL 数据库是否需要更多规范化时。

于 2009-11-03T14:21:30.170 回答

score 1 · Accepted Answer

3NF 通常是您所需要的，它遵循三个规则：

表中的每一列都应依赖于：

出于性能原因，您通常可以“降级”到 2NF，前提是您了解其含义并且仅在遇到问题时才可以，但是 3NF 应该是您所有设计的初始目标。

score 1 · Accepted Answer

正如其他人所说，您知道何时开始在多个表中拥有（太多）重复列。

话虽如此，有时跨多个表具有冗余列很有用。这可以减少您在复杂查询中必须执行的 JOIN 数量。请注意保持所有表同步，否则您只是在自找麻烦。

score 0 · Accepted Answer

这是一篇相当不错的文章。恢复正常是一门科学，而不是一门艺术。现在知道何时去规范化......这是一门艺术。

score 0 · Accepted Answer

0

于 2009-11-03T14:25:58.387 回答

score 0 · Accepted Answer

您目前处于什么标准化水平？如果你不能回答我认为你的数据库是一团糟。我总是在初始设计中达到第三个正常值，并在需要时进一步去规范化或规范化。

score 0 · Accepted Answer

我假设您正在谈论支持交互式应用程序的事务数据库，但它的价值......

专门用于报告且仅由 ETL 流程更新的 OLAP 数据库可能会受益于标准化程度较低的结构。在这些应用程序中，您可以接受冗余数据存储和复制的成本，以获得更少的连接和更高的易用性（有时是技术含量较低的）数据分析师和业务分析师的性能优势。

事务数据库应始终在实际范围内进行规范化（至少 3NF），然后仅在需要时选择性地非规范化。理想情况下，反规范化的需要应该基于实际的性能测试结果。

score -1 · Accepted Answer

当您必须搜索大量数据以提取一些基本信息时 - 即那里有什么样的产品类别或类似的东西。

13 回答 13