何时将数据库设计描述为过度标准化？这种特征是绝对的吗？或者它取决于它在应用程序中的使用方式？谢谢.
从一般意义上讲,我认为过度规范化是指当你执行如此多的JOIN来检索数据时,它会导致显着的性能损失和数据库死锁,即使在你调整了索引之后也是如此.显然,对于像MySpace或eBay这样的大型应用程序和网站,去规范化是一种扩展要求.
作为几家小型企业的开发人员,我告诉你,根据我的经验,从规范化 - >非规范化而不是相反的方式变得更容易,实际上是反过来(以避免现在的业务重复要求已经改变了一年左右)更难.
当我读到诸如"你应该把地址放在你的客户表中而不是单独的地址表中以便你可以避免加入"这样的一般性陈述时,我不寒而栗,因为你只知道从现在起一年后有人会要求你做您完全没有预见的地址,例如维护审计跟踪或每个客户存储多个地址.如果您的数据库允许您创建索引视图,则可以回避该问题,直到您的数据集如此之大以至于不可能存在或由1-中的单个服务器或服务器集提供服务为止.写,多读环境.对于我们大多数人来说,我不认为这种情况会经常发生.
如果有疑问,我会瞄准第三范式而有一些例外(例如,有一个字段包含分隔字符串的CSV列表,因为我知道我永远不会从另一个角度查看数据).当我需要整合时,我会首先查看我的观点或索引.希望这可以帮助.
它始终是应用程序域的问题.这通常是正确性的问题,但偶尔也会出现性能问题.
有一种情况我可以想象一个过度标准化的初步证据:说你有订单+订单,订单项引用productID,并将价格留给product.price.由于这引入了时间耦合,因此过度标准化会影响已经发货的订单,因为这种情况绝对不会发生变化.你当然可以说这只是一个建模错误(如评论中所述),但我认为在大多数情况下,规范化不足也是一种建模错误.
另一类是与绩效相关的.原则上,我认为通常有更好的解决方案来实现比非规范化数据,例如物化视图,但如果您的应用程序遭受许多连接的性能影响,那么可能值得评估非规范化是否可以帮助您.我认为这些案例经常被过分强调,因为人们有时会在正确描述其应用之前达到非规范化.
人们也经常忘记替代方案,例如保持数据库的规范形式,并使用仓库或其他策略来频繁阅读但不经常更改的数据.
标准化是绝对的.数据库遵循普通表格,或者不遵循.有六种正常形式.大多数情况下,他们的名字从第一到第五.另外还有Boyce-Codd Normal Form.
归一化仅用于一个目的 - 防止"更新异常".
归一化不是主观的.这不是判断.表中的每个表和关系都遵循或不遵循正常形式.
因此,您不能"过度规范化"或"规范不足".
话虽如此,规范化具有性能成本.有些人选择以各种方式进行非规范化以提高性能.最常见的合理的非规范化是打破3NF并包括派生数据.
一个常见的错误是打破2NF并在密钥和非密钥值之间具有功能依赖的重复副本.这需要额外的更新或 - 更糟糕 - 触发器以保持副本并行.
事务数据库的非规范化应该是个案情况.
数据仓库也很少遵循任何事务规范化规则,因为它(基本上)从未更新过.
"过度规范化"可能意味着数据库因为大量连接而太慢.这也可能意味着数据库已经超出了硬件.或者说应用程序还没有按比例设计.
这里最常见的问题是人们在事务进行时尝试使用事务数据库进行报告.事务锁定会干扰报告.
但是,"规范不足"意味着存在NF违规,并且正在进行不必要的处理以处理复制的数据并纠正更新异常.
京公网安备 11010802040832号 | 京ICP备19059560号-6 