这个问题可能更适合programmers.stackexchange。如果是，请迁移。
我目前正在思考典型数据模型的复杂性。每个人都知道数据模型应该被规范化，但是另一方面，规范化的数据模型将需要相当多的连接来重新组装数据。连接可能是昂贵的操作，具体取决于所涉及的表的大小。所以我想弄清楚的问题是，人们通常会如何进行这种权衡？即在实践中，在设计数据模型时，您会发现在典型查询中可以接受多少个连接？当计算单个查询中的多个连接时，这将特别有趣。
举个例子，假设我们有用户，他们拥有房屋，其中有房间，有抽屉，里面有物品。在上面解释的意义上，用用于用户、房屋、房间、抽屉和项目的表来简单地规范化这一点，稍后在获取属于某个用户的所有项目时，我需要加入五个表。这对我来说似乎非常复杂。
很可能还会涉及表格的大小。连接五个数据量很少的表并不像连接数百万行的三个表那么糟糕。还是这种考虑是错误的？
数据库规范化是有原因的，我已经看到有超过 20 个表和子查询的查询被连接在一起，很长一段时间都可以正常工作。我确实发现规范化的概念是一个巨大的胜利，因为它允许我将新功能添加到现有的工作应用程序中，而不会影响迄今为止的工作部分。
数据库具有不同的功能，可让您的生活更轻松：
不久前有一个相关的问题，关于包含多个连接的 SQL 语句如何工作？也可能值得研究一下。
使用规范化数据库开发应用程序更容易，因为通过适当的方法，您可以通过视图/函数隔离您的架构，并使您的应用程序代码不受架构更改的影响。如果您选择非规范化设计，那么设计更改可能会影响您的大量代码，因为非规范化系统往往会以更改可能性为代价进行高性能优化。
规范化数据库本身就是一种艺术形式。
如果你正确地构建你的连接，你只会抓住需要的列。
运行具有多个表的数百万条记录并仅加入所需字段的查询应该要快得多，然后如果您说一两个表包含所有记录，它会更快。在第二个示例中，您正在检索所有数据并对其进行排序将是一场编码噩梦。
MySQL 非常好只检索请求的数据。
仅仅因为查询很长并不意味着它更慢。
我见过超过 20 行非常快的查询语句。
对您编写的查询有信心，如果您不编写测试脚本，请自己尝试。
完全规范化的数据模型在性能上具有更大的成本，但对变化更具弹性。为一个查询调整的一角钱的扁平数据模型会表现得更好，但是当规格发生变化时，您将不得不付出代价。
所以也许问题是您的数据模型（查询）的使用会发生很大变化吗？如果不; 不要对它们进行规范化，只针对特定查询调整它们（询问您的 DBA）。否则，如果您使用多个连接，请规范化并仅通过查询执行计划，我不能给您一个具体的数字。
为了解决您的问题，答案在：
http://en.wikipedia.org/wiki/Database_normalization
如果性能成为使用非规范化的问题，则可以解决这些问题。不应该预先考虑这一步（除非您已经有预期的负载）。在真正需要并基于测量值时进行非规范化。