如果我有表A和表B，并且我的数据在表A中开始但最终在表B中，并且我有一个表C指向A的主要键，但是当数据从A中删除并结束在表B中时，应该指向B(具有与A数据相同的ID(。这会引起困惑吗？这是表明我的意思的例子：
a(待处理结果(id = 3
b(完成的结果(null
c(用户(id = 1结果ID = 3(A和B的外键(
三分钟后，结果发布了。
a(待处理结果(null
b(完成的结果(id = 3
c(用户(id = 1结果ID = 3(A和B的外键(
此实现有什么问题。还是将A和B作为一张桌子更好？桌子可能会很大，这是我担心的。作为单独的表，对表A的读取将远大于表B和表A的读取要小得多，因为它只是待定的结果。如果将A和B合并到一张桌子中，那么这既是待定的，也是所有已完成结果的历史，因此找到正在待处理的结果将需要更多的时间。如果这有所不同，所有这些都将完成。
所以我想我的问题是：该实现适合中等规模，还是我刚才说的信息，我是否应该组合表A和B大得多(。
听起来您已经发现这不起作用。我无法正确效法您的榜样，因为" A"，" B"one_answers" C"对我永远不起作用。我怀疑这些公式化标签比其他人的细节要好。。您只是无法获胜；-)无论如何，听起来您对桌面大小面临实际关注，并且很想使用将自然桌子分为两个部分的设计。(Hot and Old。(正如您发现的那样，这实际上与系统中的键无效。关系模型(等(没有一个概念："这东西是这个或那个的孩子"。因此，您正在那里游泳。无论如何，这种设置在野外非常普遍，以至于有一个名字。好吧，几个名字。比尔·卡尔文(Bill Karwin(的 sql抗模式的"多态性关联"很常见。顺便说一句，那是一本好书，简而言之。同样，"混杂协会"也是您会看到的术语。或者有时您会看到表本身被列为"跳台"或"集线器"，等等。
我怀疑这种非关系模式是如此广泛使用的原因：对人类来说是有意义的。当您拥有某种东西的东西时，关系模型总是很紧密的领域。就像是员工或学生的人。这么多共同的领域，有许多与其特定类型不同的领域。一张桌子？二？三？Postgres中的表继承可能会有所帮助...至少它正在尝试。无论如何，多态关系在RDBMS中是有问题的，因为它们无法自动建模或约束。您需要自定义代码来确定该记录是该表的孩子...或其他表。您不能将其烘烤到关系中。如果您对此设计问题的各种解决方案感兴趣，那么Karwin的章节非常好，易于阅读，并且充满了替代设计。如果您不想追踪这本书，但有点感兴趣，请查看几年前的这篇文章：
https://hashrocket.com/blog/posts/modeling-polymorphic-associations-in-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-patabase
机会是，您现在的兴趣是日常的。听起来您有一条带有一些有效记录的处理管道和不断增加的旧记录集合。您没有提及您的Postgres版本，但是您可能比想象的要少担心。首先，您可以考虑对表进行分区。一个分区的表具有一个单个逻辑表，您可以在查询中与引擎盖下方的较小物理表的集合进行交谈。您可以直接获取分区，但不需要。您只需与my_big_table交谈，然后Postgres弄清楚在哪里看。因此，您可以在每周，月份等分开数据。这样，每个桶都对您来说太大了。在这种情况下，各个分区也有自己的索引。因此，您最终会得到较小的桌子和引擎盖下的较小索引。为此，最好使用PG 11或PG 10。分区是一个大主题，而Postgres功能集并不是每种情况的完美匹配……您必须在其范围内工作。我现在就把它留下来，因为它可能不是您首先需要的。
比分区更简单的是 avesome postgres功能，您可能不知道，部分索引。这并不是Postgres所唯一的(SQL Server称其为"过滤"索引相同的功能(，但我认为MySQL没有。好的，这个想法真的很简单：构建一个仅包含与条件匹配的行的索引。这是一个例子：
CREATE INDEX tasks_pending
ON tasks (status)
WHERE status = 'Pending'
如果您的表有100m记录，则完整的B树必须对所有100m行进行分类。您需要在主钥匙上进行唯一性检查...但是它又大又昂贵。现在想象一下，您的100m记录只有1,000行，其中=待处理。您只有1,000行有一个索引。微小，快速，完美。这里的美容部分是，随着历史数据集的增长，部分索引不一定会变大。而且，大声喊叫历史数据集，当您需要获得聚合等时，它们非常在简单的搜索中很高兴。如果将内容分成多个表，则需要使用Union编写更长的查询。(在逻辑分区主表掩盖物理部门的分区中，情况并非如此。(
hth