我们正在 mySQL Workbench 的帮助下为一个新的应用程序绘制数据库结构，并且随着多对多关系的增加，列出数据所需的连接数量急剧增加。
应用程序的读取量很大，每个表有几十万行。
问题：
在需要的地方合并表从而减少连接真的有那么糟糕吗？
我们应该开始研究水平分区吗？ （结合合并表）
有没有比数据透视表更好的方法来处理多对多关系？
我们讨论了将所有数据存储在序列化文本列中并让应用程序而不是数据库进行排序，但这似乎是一个非常糟糕的主意，即使数据库将被大量缓存。你怎么看？
【问题讨论】：
标签： mysql database-design data-structures relational-database database-relations
如果您确保索引外键（您确实设置了外键，不是吗？）并且在查询中有适当的 where 子句，数据库应该可以轻松处理 10-15 个连接。尤其是这么少的行。我对具有数百万行的表进行了这么多连接的查询，并且它们运行良好。
通常对数据进行分区比反规范化更好。
就去规范化而言，除非您还制定了保持去规范化数据与父表同步的策略，否则不要这样做。
至于您是否真的需要这么多表，或者您的设计是否糟糕，我们唯一可以评论的方法就是我们看到表结构。
【讨论】：
除非您有明确的证据表明性能因连接而受到影响，否则请保持正常化。否则，正如其他人所说，您将不得不担心多次更新。
特别是如果数据库被大量缓存，如您所说，您会惊讶于 DBMS 做这种事情的速度之快——毕竟这是它的设计目的。
除非是具有大量数据的怪物应用程序需要特殊的性能优化，否则您会发现减少开发、测试和后期维护工作将更为重要。
连接通常很好，也不错。它们允许您将数据保留在应有的位置，从而为您提供最大的灵活性。
正如已经多次说过的那样，过早的优化通常是坏的，不是好的。
【讨论】：
数据库旨在处理大量连接。使用此功能，因为它将使数据库中的多种数据操作变得更加容易。否则，为什么不直接使用平面文件呢？
【讨论】：
使用数据库的规范化形式。对于大部分任务，您不需要超过 3 或 4 个联接，您仍然可以为最常见的联接编写视图。非规范化将让您在更改一个属性时始终考虑更新多个位置/表中的字段，并且肯定会导致更多的问题而不是好处。
如果您担心报告性能，您仍然可以将数据分批提取到单独的表中，以获得报告查询所需的性能。如果是为了查询简单，您可以使用视图。
【讨论】：
倒序：
算了。使用数据库。人们说“在应用程序中实现它”通常是那些对编写数据库的工作量一无所知的人。
取决于具体需要。
取决于具体需要。 OLTP（事务处理） - 寻求第一种范式。 OLAP（分析处理）- 寻找适当的星图并进行非规范化以获得最佳性能。混合 - 算了。不适用于较大的安装，因为理论不同...除非您将数据库设置为 OLTP，然后使用特殊的 OLAP 多维数据集数据库（mySQL 没有）。
【讨论】：
与往常一样，这取决于您的应用程序，但一般来说，过多的非规范化可能会在以后再次出现并咬您一口。一个良好规范化的数据库意味着您应该能够以您以后可能需要的大多数方式查询您的数据，尤其是用于报告（这通常是事后才想到的）。
如果您将所有数据粘贴在序列化的文本列中，并且您的客户要求一份报告显示所有具有特定属性的行，那么您将不得不进行一系列字符串操作才能获取这些数据。
如果您担心查询的连接过多，可以考虑将某些数据集公开为视图...
【讨论】：