在设计数据库（例如 MySQL）的模式时，会出现是否完全规范化表的问题。
一方面，连接（以及外键约束等）非常慢，另一方面，您会获得冗余数据和潜在的不一致。
“最后优化”是正确的方法吗？即创建一个按书本规范化的数据库，然后查看可以对哪些内容进行非规范化以实现最佳速度增益。
对于这种方法，我担心的是，我将选择可能不够快的数据库设计 - 但在那个阶段重构模式（同时支持现有数据）将非常痛苦。这就是为什么我想暂时忘记我所学到的有关“正确”RDBMS 实践的所有内容，并尝试一次“平面表”方法。
该数据库将大量插入的事实是否会影响该决定？
一个哲学答案：次优（关系）数据库充斥着插入、更新和删除异常。这些都会导致数据不一致，导致数据质量较差。如果您不能相信数据的准确性，那有什么好处呢？问问自己：你想要更慢地得到正确答案还是想要更快地得到错误答案？
作为一个实际问题：在快速得到它之前先把它做好。我们人类非常不擅长预测哪里会出现瓶颈。使数据库变得出色，在相当长的一段时间内测量性能，然后决定是否需要使其更快。在非规范化和牺牲准确性之前，请尝试其他技术：您可以获得更快的服务器、连接、数据库驱动程序等吗？存储过程可能会加快速度吗？索引及其填充因子如何？如果这些和其他性能和调优技术不起作用，那么才考虑非规范化。然后测量性能以验证您是否获得了“支付”的速度提升。确保您正在执行优化，而不是悲观化。
[edit]
问：那么如果我最后优化，你可以吗
推荐合理的迁移方式
架构更改后的数据？如果，
例如，我决定摆脱
查找表 - 如何迁移
这个新设计的现有数据库？
答：当然可以。
- 进行备份。
- 再次备份到不同的设备。
- 使用“select into newtable from oldtable...”类型命令创建新表。您需要执行一些联接来组合以前不同的表。
- 扔掉旧桌子。
- 重命名新表。
BUT...考虑更稳健的方法：
立即在完全标准化的表上创建一些视图。这些视图（虚拟表、数据的“窗口”...询问我是否想了解有关此主题的更多信息）将具有与上面第三步相同的定义查询。当您编写应用程序或数据库层逻辑时，请使用视图（至少用于读取访问；可更新的视图……嗯，很有趣）。然后，如果稍后进行非规范化，请如上所述创建一个新表，删除视图，无论视图是什么，都重命名新的基表。您的应用程序/数据库层不会知道其中的区别。
实际上，在实践中还有更多内容，但这应该可以帮助您入门。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
