数据库结构 - 加入或不加入

Question

我们正在借助mySQL Workbench为新应用程序绘制数据库结构，随着多对多关系的增加，制作数据列表所需的连接数量也在急剧增加。

应用程序将非常重读，每个表有几十万行。

问题：

• 在需要的地方合并表并因此减少连接真的很糟糕吗？

• 我们应该开始考虑水平分区吗？ （与合并表一起使用）

• 是否有更好的方法来透视表来处理多对多关系？

• 我们讨论过将所有数据存储在序列化文本列中并让应用程序进行排序而不是数据库，但这似乎是一个非常糟糕的主意，即使数据库将被高度缓存。你觉得怎么样？

Answer 1

使用数据库的规范化形式。对于大多数任务，您不需要超过3或4个连接，您仍然可以为最常见的连接编写视图。非规范化将让您在更改一个属性时始终考虑更新多个位置/表中的字段，并且肯定会导致更多问题而不是好处。

如果您担心报告性能，那么您仍然可以将定时批量数据提取到单独的表中，以获得报告查询所需的性能。如果是为了简化查询，您可以使用视图。

Answer 2

按相反顺序：

• 算了。使用数据库。人们说，“在应用程序中制作它”通常是那些对编写数据库的工作量无知的人。

• 取决于确切需要。

• 取决于确切需要。 OLTP（交易处理） - 寻找正常形式。 OLAP（分析处理） - 寻找合适的星图并进行非规范化以获得最佳性能。混合 - 忘了。不适用于较大的安装，因为理论是不同的...除非您使数据库OLTP然后使用特殊的OLAP多维数据集数据库（mySQL没有）。

Answer 3

数据库旨在处理大量连接。使用此功能，因为它将使数据库中的多种数据操作更容易。否则，为什么不使用平面文件？

Answer 4

与往常一样，这取决于您的应用程序，但总的来说，太多的非规范化可能会再次出现并在以后咬你。规范化的数据库意味着您应该能够以稍后可能需要的大多数方式查询数据，尤其是报告（通常是事后的想法）。

如果您将所有数据都放在序列化文本列中，而客户端要求显示所有具有特定属性的行的报告，那么您将不得不进行一系列字符串操作以获取此数据。< / p>

如果您担心查询的连接太多，您可以考虑将某些数据集公开为视图......

Answer 5

如果确保索引外键（你确实设置了外键吗？）并且在查询中有适当的where子句，数据库应该可以轻松处理10-15个连接。特别是行数如此之少。我有数百万行的表上有很多连接的查询，它们运行正常。

通常，对数据进行分区比对非规范化更好。

就去大规模而言，除非你还制定了一个保持非规范化数据与父表同步的策略，否则不要这样做。

至于你是否真的需要那么多的表，或者你的设计是不是很糟糕，我们唯一可以评论的方法是看看表结构。

Answer 6

除非您有明确的证据表明因为加入而导致表现受到影响，否则请保持正常化。否则，正如其他人所说，你将不得不担心多次更新。

特别是如果数据库被大量缓存，正如你所说，你会惊讶于DBMS在做这类事情时有多快 - 毕竟它是它的设计目的。

除非它是那种具有大量数据的怪物应用程序，需要特殊的性能优化，否则你会发现保持开发，测试以及后来的维护工作将会更加重要。

加入很好，通常也不错。它们允许您将数据保存在应有的位置，从而为您提供最大的灵活性。

正如多次所说，过早优化通常很糟糕，不好。