拥有多个用于存储相同类型对象的表有什么好处吗？

Question

假设我想将歌曲存储在我的数据库中。我有十个表，而不是只有一个Song表。Song表还具有Artist表的外键。当一个艺术家被添加到数据库中时，我们检查每个Song表中到底有多少首歌，并且我们用最少的歌曲分配给艺术家。艺术家的所有歌曲都将存储在那个Song表中。

我不想把1M个对象存储在一个表中，而是将它们分成10块，每个约100 k个对象，并将它们存储在10个不同但结构相似的表中。现在，如果艺术家对象中的歌表引用从未改变，我的整个系统会不会更快，更好的表现？

我意识到一个大问题是找到单个歌曲，但请回答以下问题:只有通过提供两个参数，才能从数据库中检索歌曲：

• artist_id
• song_id

如果我有artist_id，我可以使用它来获取我的艺术家对象，它包含对包含歌曲的歌表的引用，其中包含带有song_id给予的歌曲的歌曲。所以，如果我有artist_id，我就不必查询10个不同的表来查找歌曲，情况总是如此。

这会完全没用吗？还是会对我的系统性能产生积极的影响？

注意:我意识到歌曲不应该以这种方式存储，因为你想在不认识艺术家的情况下查询歌曲，但这只是一个例子，尽管很糟糕。此外，请忽略这样一个事实，即在回答时，这些代码和管理都会很混乱。我只想知道性能影响.

Answer 1

在同一个数据库中将一个逻辑表划分为多个表没有任何好处。这将使查询复杂化，实际上可能会影响性能，因为查找元素更加困难。与简单的查询不同，您必须对每个表重复查询，然后接受结果的UNION。

在管理良好的数据库中，在表中拥有数百万或数十亿个元素根本不是问题。您需要适当的索引才能获得可承受的查询性能，但无论如何，您都应该这样做。

有时，“表”实际上是分开的，这样它就可以分布在多个数据库或分布式数据库的多个节点上。如果由于硬件限制，单个数据库不足以提供所需的读/写性能，则这称为分片。然而，也有一些缺点。

• 我们只能用一个键来分割，例如歌曲ID。
• 在一种简单的切分方法中，我们按ID范围分割，一个节点可能有旧元素，一个节点有新元素，这会导致节点之间的负载不均匀。因此，数据库应该更喜欢GUID而不是顺序ID，或者使用哈希函数。
• 从分片数据库集群中添加或删除节点也很困难。
• 如果不能通过切分键解析数据库查询，则必须对每个碎片重复查询，然后将结果合并为map-还原样式。这可以放大负荷，而不是减少负荷。
• 最重要的缺点是:分片数据库通常不能执行涉及多个条目的事务性更新，但这是高度依赖于软件的。

许多数据库都内置了对切分的支持。SQL数据库可以透明地按其主键对表进行划分--而不必修改任何查询(但请参阅数据库手册中的警告，例如，这是否会放松某些ACID保证)。逻辑表结构(通过SQL公开)和物理表结构(例如存储引擎和索引数据结构)之间的这种清晰的分离是SQL数据库的主要特性！

在可能的情况下，使用读副本数据库可能比分片更可取。所有写入都会转到主数据库，但是读取的负载可以分布在副本之间。事务性更新仍然是可能的，尽管从副本中读取可能已经过时。

因此，数据库有许多提高性能的技术，例如跨多个节点的分片。但是，在许多情况下，这可以透明地完成，您不应该在预期的情况下修改您的表结构。很有可能，您不需要任何扩展技术，而且一个数据库在设计良好时将能够提供足够的性能(适当的ER建模，使用索引，不要过度标准化，…)。

Answer 2

为了扩展以前的注释-关系数据库系统通常能够存储数十亿(！)如果有必要的话，它们包含特定的机制--比如“表空间”--来管理实际存储所有数据的后端物流。平衡--像你所说的那样的决策可以透明地由数据库系统本身来处理。

大多数公司最终不得不存储他们的数据，“本质上，永远。”他们可以通过创建单独的“归档”表来做到这一点，但现代数据库提供了其他选择，可以将较少使用的数据或存档数据隔离到其他地方，同时将其作为单一图像保持完全可访问性。