是在您尝试获取数据并且没有明显的简单方法时吗?
当你发现某个东西应该是一张自己的桌子?
有哪些法律规定?
是在您尝试获取数据并且没有明显的简单方法时吗?
当你发现某个东西应该是一张自己的桌子?
有哪些法律规定?
当您注意到您必须重复相同的数据时,或者当您开始使用单个字段作为数组时。
虽然这是一个有点刻薄的答案,但当您发现数据没有充分标准化时。网络上有很多关于规范化级别(或者更准确地说是“形式”)的资源,它们比我在这里更完整地描述了这些形式。应该非常需要第一和第二范式。如果你不是第三(或者,实际上,第四)范式,你需要有一个强有力的理由来解释为什么。
只要你有一个关系数据库......<grin/>
不,实际上有法律,请查看此 Wikipedia链接。
它们被称为五种范式或类似的东西。最初来自于 50 年代/60 年代发明关系数据库的人 EF Codd。
“钥匙就是钥匙,只有钥匙,所以帮我科德”
这是一个概要:
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).
当您开始质疑 SQL 数据库是否需要更多规范化时。
3NF 通常是您所需要的,它遵循三个规则:
表中的每一列都应依赖于:
出于性能原因,您通常可以“降级”到 2NF,前提是您了解其含义并且仅在遇到问题时才可以,但是 3NF 应该是您所有设计的初始目标。
正如其他人所说,您知道何时开始在多个表中拥有(太多)重复列。
话虽如此,有时跨多个表具有冗余列很有用。这可以减少您在复杂查询中必须执行的 JOIN 数量。请注意保持所有表同步,否则您只是在自找麻烦。
这是一篇相当不错的文章。恢复正常是一门科学,而不是一门艺术。现在知道何时去规范化......这是一门艺术。
http://www.alvechurchdata.co.uk/hints-and-tips/softnorm.html
您目前处于什么标准化水平?如果你不能回答我认为你的数据库是一团糟。我总是在初始设计中达到第三个正常值,并在需要时进一步去规范化或规范化。
我假设您正在谈论支持交互式应用程序的事务数据库,但它的价值......
专门用于报告且仅由 ETL 流程更新的 OLAP 数据库可能会受益于标准化程度较低的结构。在这些应用程序中,您可以接受冗余数据存储和复制的成本,以获得更少的连接和更高的易用性(有时是技术含量较低的)数据分析师和业务分析师的性能优势。
事务数据库应始终在实际范围内进行规范化(至少 3NF),然后仅在需要时选择性地非规范化。理想情况下,反规范化的需要应该基于实际的性能测试结果。
当您必须搜索大量数据以提取一些基本信息时 - 即那里有什么样的产品类别或类似的东西。