一张大桌子或许多小桌子

Question

我有一个将修改记录记录到表中的数据库。此修改表包含其他表的外键（修改表仅包含对修改对象的引用）。 此修改表中的对象可以分组到不同的群体中。当用户访问服务时，他只向数据库请求关于他的人口的对象。 我每周将有大约 2 到 10 个新种群。

1. 智能手机经常请求此表，其中包含大约 500 000 / 1 000 000 条记录。
2. 如果我将修改表拆分为多个表，则无需执行表连接来回答用户请求

如果我把这个单表改成多表，我想会加快响应时间。

但另一方面，修改表中的每个“插入”都需要首先具有目标表的名称（这意味着另一个请求）。为此，我计划在“人口”表中有一个列，其中一个 varchar 表示要修改的目标表。

我的问题是设计模式/架构问题 --> 我应该选择一个非常大的桌子，每个请求都有 3 个“位置”，还是应该尝试许多没有“位置”的轻型桌子玩吗？

Answer 1

500K - 100 万条记录并非微不足道 - 但它当然也不大。你的数据库平台是什么？大多数主流专业平台（SQL、Oracle、MySQL 等）都能够处理这个问题。

如果所讨论的表很窄（列数很少），那么与包含很多列的“宽表”相比，它不太可能成为问题。

有很多连接可能是一个问题（我只是不能根据经验说话）。根据您管理事物的方式（以及您的应用程序代码有多好），您真的需要外键约束吗？

Answer 2

最干净的方法是使用一张桌子并在人口上使用partition。为此进行了分区。