采用数据库的规范化形式。对于大部分任务，您不需要超过3或4个连接，仍然可以为最常见的连接编写视图。反规范化将使您始终考虑在更改一个属性时在多个位置/表中更新字段，并且肯定会带来比好处更多的问题。
如果您担心报告性能，则仍然可以将数据定期批量提取到单独的表中，以获得所需的报告查询性能。如果是为了查询简单性，则可以使用视图。
倒序列出:
算了吧，使用数据库。那些说“在应用程序中制作它”的人往往对编写数据库所需的工作量一无所知。
取决于确切的需求。
取决于确切的需求。OLTP（事务处理）-采用第五范式。OLAP（分析处理）-采用适当的星型图并进行去规范化以获得最佳性能。混合-算了吧。由于理论不同，对于较大的安装无效...除非您使数据库成为OLTP，然后使用特殊的OLAP立方体数据库（mySQL没有）。
数据库被设计用于处理大量的连接。利用这个特性可以使得在数据库中进行许多种数据操作变得更加容易。否则，为什么不直接使用平面文件呢？
通常来说，这要看你的应用程序，但过度反规范化可能会在以后带来麻烦。规范化良好的数据库意味着您应该能够以后可能需要的大多数方式查询数据，特别是对于报告（通常是后期想起来的）。
如果您将所有数据都放在序列化文本列中，并且您的客户要求显示具有特定属性的所有行的报告，则必须执行一些字符串操作才能获取此数据。
如果您担心查询过多的连接，可以考虑将某些数据集公开为视图...
如果您确保索引了外键（您设置了外键，对吧？）并在查询中有适当的where子句，那么数据库应该可以轻松处理10-15个连接。特别是对于如此少的行数。我有一些查询涉及到数百万行的表格，但它们运行得很好。
通常情况下，最好对数据进行分区而不是去规范化。
至于去规范化，除非您还制定了一种策略来使规范化的数据与父表同步，否则不要这样做。
至于您是否真的需要那么多表格或者您的设计是否不好，唯一能够评论的方式就是看到表格结构。
除非你有明确的证据表明连接操作影响了性能，否则保持规范化。否则，就像其他人所说的那样，你将不得不担心多次更新。
特别是如果数据库被大量缓存，正如你所说的那样，你会惊讶于DBMS在执行这种操作时的速度有多快 - 毕竟这就是它的设计目的。
除非它是那种需要特殊性能优化的大型应用程序，具有大量数据，否则保持开发、测试和后期维护的努力更为重要。
连接通常是好的，而不是坏的。它们允许你将数据放在应该放置的位置，从而给你最大的灵活性。
正如已经说过很多次的那样，过早地进行优化通常是不好的，而不是好的。
