一张巨大的桌子或许多小桌子

Question

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

1. 这张表非常经常被智能手机要求，并且包含大约500 000/1 000 000条记录。
2. 如果我将修改表拆分为多个表，则没有用于回答用户请求的表连接

如果我将这个表改成多个表，我猜它会加快响应时间。

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

我的问题是设计模式/架构 - ＆gt;我应该为每个请求选择一个非常大的桌子，每个请求有3个“where”，或者我应该尝试一下没有“在哪里”播放的许多光桌？

Answer 1

最干净的事情是在人群中使用一个表格partition。分区就是为此做的。

Answer 2

<500> - 1M记录并非微不足道 - 但它肯定也不是很大。你的数据库平台是什么？大多数主流专业平台（SQL，Oracle，MySQL等）都能够处理这个问题。

如果有问题的表格很窄（列数很少），那么它就不太可能成为一个问题而不是具有大量列的“宽表”。

有很多连接可能是个问题（我根本无法从经验中说出来）。根据您的管理方式（以及您的应用程序代码有多好），您真的需要外键约束吗？