我正在尝试理解数据库中的非规范化，但谷歌几乎所有关于吐出的文章都针对高级数据库管理员。我对MySQL和MSSQL有相当多的了解，但我无法理解这一点。
当速度成为一个问题时，我能想到的唯一例子是在我以前实习的地方对两张桌子中的大约2,500,000行进行计算。正如你可以猜到的那样，按需计算这么多，并且冻结了我所使用的开发服务器几分钟。因此，在我离开主管之前，我想要编写一个计算表来保存所有预先计算的值，并且每小时左右更新一次（这是一个经常不使用的内部站点）。但是我没有完成它，因为我离开了
这会是非规范化的一个例子吗？如果是这样，这是一个很好的例子还是它走得更远？如果没有，那么简单来说是什么呢？
答案 0 :(得分：2)
假设您有一个Excel文件，其中包含2个要用于存储家庭联系详细信息的工作表。在第一个工作表上，您可以使用手机号码获取联系人的姓名。在第二个工作表上，您有每个家庭的邮寄地址及其固定电话号码。
现在，您要为所有姓名打印圣诞卡片标签，列出所有姓名，但每个邮寄地址只有一个标签。
您需要一种方法来链接两个规范化集。您拥有的2套中的所有数据都已标准化。它是“原子的”，代表一个“原子”或一条无法分解的信息。没有一个重复。
在2组的非规范化视图中，您将拥有一个重复多次邮件地址的所有联系人列表（表兄Alan和Bob叔叔住在同一地址，因此它列在Alan和Bob的行中。 ）
此时，您希望在两个集合中引入家庭ID以链接它们。每个邮寄地址都有一个家庭ID，每个联系人都有一个可以重复的家庭ID值（堂兄艾伦和叔叔鲍勃，住在同一个家庭，有相同的家庭ID。）
现在说我们正在工作，我们需要跟踪数以万计的联系人和家庭。保持数据标准化非常适合维护，因为我们只想在一个地方存储联系人和家庭详细信息。当我们更新地址时，我们会为所有相关联系人更新地址。不幸的是，出于性能原因，当我们要求服务器加入这两个相关集时，它需要永远。
因此，一些开发人员出现并创建了一个非规范化的表，其中包含所有数量的行，每个联系人对应一个家庭详细信息。性能得到改善，空间考虑因素被抛到窗外，因为我们现在需要3亿行而不是2行。
有意义吗？
答案 1 :(得分：1)
我会称聚合而不是非规范化（如果是订单数量，例如每天的SUM（订单）......）。这就是OLAP的用途。例如，非规范化将不是在Contact表中使用PhoneType表和PhoneTypeID，而是在Contact表中使用PhoneType，从而消除1个连接
您当然也可以使用索引/物化视图来聚合值...但现在您将减慢更新，删除和插入
触发器也是实现此目的的另一种方法
答案 2 :(得分：1)
在一种过于简化的形式中，我会将去规范化描述为减少用于表示相同数据的表的数量。
客户和地址通常保存在不同的表中，以允许一个客户拥有多个地址的概念。 （工作，家庭，当前地址，以前的地址等）
同样可以说适用于姓氏和其他财产，但只有当前的姓氏才会引起关注。因此，可以将所有方式规范化为具有Customer表和Surname表，具有外键关系等。但是然后通过将两个表合并在一起来反规范化。
“正常化直到它受伤”的好处在于它迫使人们考虑纯粹的（希望）完整的数据表示以及可能的行为和关系。
“去标准化直到它起作用”的好处是减少某些维护和/或处理开销，但坚持通过计算标准化模型得出的相同基本模型。
在“Surname”示例中，通过非规范化，可以根据客户的姓氏和出生日期向客户添加索引。如果没有反规范化，Surname和DoB就在不同的表中，并且无法使用复合索引。
答案 3 :(得分：0)
非规范化可能是有益的，您提供的示例就是这样的一个实例。动态计算这些并不理想，因为成本昂贵，因此您创建一个表并具有引用另一个表以及计算值的功能ID。
数据是多余的，因为它可以从另一个表中导出，但由于生产要求，这在功能意义上是更好的设计。
很想知道其他人对这个话题的看法，因为我知道我的sql教授会对术语denormalize感到畏缩，但它具有实用性。
答案 4 :(得分：0)
普通表单将拒绝此表，因为它完全可以从现有数据派生。但是，出于性能原因，通常会发现此类数据。例如，库存计数通常是承载的，但可以从创建它们的交易中获得。
对于较小的较快集合，可以使用视图来派生聚合。这为用户提供了他们需要的数据（聚合值），而不是强迫他们自己聚合。 Oracle（和其他人？）已经引入了物化视图来执行经理的建议。这可以在各种时间表上更新。
如果更新卷允许，则可以使用触发器使用表来模拟实例化视图。这可以降低维持聚合值的成本。如果不是，它会在更长的时间内分摊开销。但是，它会增加创建死锁条件的风险。
OLAP将这个简单的案例更多地放在聚合中。分析师对聚合值感兴趣，而不是细节。但是，如果聚合值很有趣，他们可能会查看详细信息。从正常形式开始，仍然是一个很好的做法。