在为数据库（例如MySQL）设计模式时，会出现一个问题，即是否要完全规范化表。
一方面，联接（以及外键约束等）非常慢，另一方面，您会获得冗余数据和潜在的不一致情况。
这里“最优化”是正确的方法吗？即创建一个书本归一化数据库，然后查看可以进行归一化以实现最佳速度增益的内容。
对于这种方法，我的担心是，我将选择一个可能不够快的数据库设计- 但是在那个阶段重构模式（同时支持现有数据）将非常痛苦。这就是为什么我很想暂时忘记我所学到的有关“正确的” RDBMS做法的所有知识，而只尝试一次“平面”方法。
该数据库将要大量插入的事实是否会影响决策？
一个哲学上的答案：次优（关系）数据库充斥着插入，更新和删除异常。这些都会导致数据不一致，从而导致数据质量较差。如果您不相信数据的准确性，那有什么好处？问问自己：您想要正确答案的速度变慢还是想要错误答案的速度变快？
实际操作：在快速掌握之前，先弄好它。我们人类很难预测瓶颈将在何处发生。使数据库更好，在相当长的一段时间内评估性能，然后确定是否需要使其更快。在取消规范化和牺牲准确性之前，请尝试其他技术：您可以获得更快的服务器，连接，数据库驱动程序等吗？存储过程可能会加快速度吗？索引及其填充因子如何？如果这些以及其他性能和调整技术无法解决问题，请仅考虑非规范化。然后测量性能以验证您是否获得了“付费”速度的提高。确保您正在执行优化，而不是悲观。
[编辑]
问：因此，如果我最后进行优化，是否可以推荐一种在更改架构后迁移数据的合理方法？例如，如果我决定放弃查找表-如何将现有数据库迁移到该新设计？
答：可以。
但是 …考虑一种更可靠的方法：
立即在完全规范化的表上创建一些视图。这些视图（虚拟表，数据上的“窗口”……问我是否想进一步了解此主题）将具有与上述第三步相同的定义查询。当您编写应用程序或DB层逻辑时，请使用视图（至少用于读取访问；可更新的视图非常有趣）。然后，如果稍后再进行非规范化，则如上所述创建一个新表，放下视图，无论视图是什么，都将重命名新的基表。您的应用程序/数据库层不会知道两者之间的区别。
在实践中实际上还有更多，但这应该可以帮助您入门。
