在设计一个数据库（例如MySQL）的模式时，是否应该完全规范化表格是一个问题。
一方面，连接操作（和外键约束等）非常缓慢；另一方面，您会得到冗余数据和潜在的不一致性。
这里的正确方法是“最后优化”吗？即按照手册规范化DB，然后查看可以去规范化以获得最佳速度增益的内容。
我对这种方法的担忧是，我将定居在可能不够快的DB设计上-但在那个阶段重构模式（同时支持现有数据）将非常痛苦。这就是为什么我想暂时忘记我学到的关于"适当的" RDBMS实践的一切，而尝试一次“扁平表”的方法的原因。
这个DB将要大量插入，这个事实会影响决策吗？
哲学上的答案：次优（关系）数据库充满了插入、更新和删除异常。这些都会导致不一致的数据，从而导致数据质量差。如果您不能信任数据的准确性，那么它有什么用呢？问问自己：你想要更慢但正确的答案还是更快但错误的答案？
实际问题是：在追求速度之前，先把它做对。我们人类非常不善于预测瓶颈会出现在哪里。使数据库变得很棒，经过一段合理的时间测量性能，然后再决定是否需要加速。在规范化丧失准确性之前，请尝试其他技术：您可以获得更快的服务器、连接、数据库驱动程序等吗？存储过程可能会加速吗？索引及其填充因子如何？如果这些和其他性能和调整技术无法解决问题，那么只考虑非规范化。然后测量性能，以验证您获得了所“付出”的速度增加。确保您正在执行优化而不是恶化。
[编辑]
问：那么，如果我最后进行优化，您可以推荐一种合理的方法来迁移数据吗？例如，如果我决定摆脱一个查找表-如何将现有数据库迁移到这种新设计中？
答：当然。
但是…考虑更健壮的方法：
立即在您完全规范化的表上创建一些视图。这些视图（虚拟表，数据上的“窗口”...如果您想了解更多有关此主题的信息，请问我）将具有与上面第三步相同的定义查询。编写应用程序或DB层逻辑时，请使用这些视图（至少用于读取访问；可更新的视图很有趣）。然后，如果以后需要去正则化，请按上述方法创建新表，删除视图，将新基本表重命名为视图名称。您的应用程序/DB层不会注意到区别。你的数据库的使用模式（插入为主还是报告为主）一定会影响到你的规范化。此外，如果规范化表格导致显著的减速，您可能需要查看索引等方面。您正在使用哪个版本的MySQL？
一般来说，插入为主的数据库应该比报告为主的数据库更加规范化。当然，具体情况因人而异...
一个正常的设计是开始的地方；首先要做对，因为您可能不需要使它快。
关于耗时的连接的担忧通常基于对糟糕设计的经验。随着设计变得更加正常，设计中的表格数量通常会增加，而每个表格中列和行的数量会减少，连接的数量会减少，联合的数量会增加，指数变得更加有用等等。换句话说：好事情发生了。
规范化只是以正常设计的一种方式...
在操作系统上很少需要使用非规范化技术。我为一个数据模型设计了近560个表（当时是澳大利亚洲最大的J2EE系统），其中只有4个部分使用了非规范化数据。两个非规范化搜索表是为了方便复杂搜索屏幕而设计的（其中一个是物化视图），另外两个则是为了满足特定性能要求而添加的。
不要过早地使用非规范化数据来优化数据库，这会导致持续的数据完整性问题。此外，始终使用数据库触发器来管理非规范化数据 - 不要依赖应用程序来完成。
最后，如果需要提高报告性能，请考虑构建数据仓库或其他单独的非规范化结构以供报告使用。实时查看大量数据计算聚合需求的报告很少出现，通常只会在少数业务线中出现。可以做到这一点的系统往往很棘手，因此成本较高。
您实际上只需要极少量真正需要最新数据的报告，它们几乎总是操作报告，例如待办事项列表或异常报告，而且涉及的数据量很小。其他所有报告都可以推送到数据仓库中，每晚刷新一次可能就足够了。
