postgresql - 两个表的一个外键会引起混淆吗？

Question

如果我有表A和表B，并且我有从表A开始到表B结束的数据，并且我有一个表C，它有一个指向A主键的外键，但是当数据从A中删除并最终到达表B时，它应该指向B（与A的数据具有相同的id）。这会引起混乱吗。这里有一个例子来说明我的意思：
A（待定结果）
id=3
B（完成结果）
无效的
C（用户）
id=1
结果id=3（A和B的外键）
三分钟后，结果已经公布。
A（待定结果）
无效的
B（完成结果）
id=3
C（用户）
id=1
结果id=3（A和B的外键）
这个实现有什么问题吗。还是把A和B放在一张桌子上比较好？我担心的是桌子会变大。作为单独的表，对表A的读取将远远大于对表B的读取，而对表A的读取将小得多，因为它只是等待结果。如果将A和B合并到一个表中，那么它将同时是待处理结果和所有已完成结果的历史记录，因此查找待处理结果将花费更多的时间。所有这些都是postgresql做的，如果这有区别的话。
所以我想我的问题是：这个实现是否适合中等规模的应用，或者考虑到我刚才所说的信息，我是否应该将表a和表B组合起来（即使B将无限大地增长，而a只包含当前的数据，并且显著地变小）。

Answer 1

听起来你已经发现这不起作用了。我不能很好地学习你的榜样，因为“A”、“B”和“C”从来都不适合我我怀疑那些公式化的标签对其他人来说比细节更好。你就是赢不了；—）不管怎样，听起来你面临的是一个实际的问题，表的大小，并试图使用一个设计，分裂成两部分自然表。（又热又旧）正如你所发现的，这对系统中的钥匙并不起作用。关系模型（等等）没有“这个东西是这个或那个的孩子”的概念，所以，你在往上游游。不管怎样，这种设置在野外非常普遍，以至于有了名字。好吧，好几个名字。”BillKarwin的SQL反模式中的“多态关联”很常见。顺便说一句，那是本好书，而且很短。同样，“滥交”这个词你也会看到。或者有时您会看到表本身被列为“跳转表”或“集线器”等。
我怀疑这一非关系模式被如此广泛地使用是有原因的：它对人类来说是有意义的。一个关系模型总是紧绷的领域是当你拥有某种东西的时候。比如，员工或学生。有这么多共同的领域，有几个是不同于他们的特定类型。一张桌子？两个？三个？Postgres中的表继承可能有帮助……至少它正在尝试。无论如何，多态关系在RDBMS中是有问题的，因为它们不能被自动建模或约束。您需要自定义代码来确定此记录是该表或另一个表的子表。你不能把这件事扯到关系上。如果你对这个设计问题的各种解决方案感兴趣的话，Karwin的章节非常好，容易阅读，并且充满了可供选择的设计。如果你不想追踪这本书，但有点感兴趣，请看几年前的这篇文章：
https://hashrocket.com/blog/posts/modeling-polymorphic-associations-in-a-relational-database
很有可能，你现在的兴趣越来越浓厚了。听起来你有一个处理管道，里面有一些活动的记录，还有越来越多的旧记录。你没有提到你的Postgres版本，但你可能比你想象的要少担心。首先，可以考虑对表进行分区。分区表有一个单独的逻辑表，您可以在查询中使用一组较小的物理表进行对话。您可以直接访问分区，但不需要。你只要和我的大桌子谈谈，博士后就知道去哪里找。所以，你可以将数据按周、月等进行拆分，这样就不会有一个桶对你来说太大了。在这种情况下，各个分区也有自己的索引。所以，最终会得到更小的表和更小的索引。为此，你最好使用第11页，或者也许是第10页。分区是一个很大的主题，Postgres特性集并不是适合每种情况的完美匹配……您必须在它的限制范围内工作。我现在就不说了，因为这可能不是你首先需要的。
比分区更简单的是一个你可能不知道的很棒的Postgres特性，部分索引。这并不是Postgres所独有的（SQL Server将同一类特性称为“过滤”索引），但我认为MySQL没有。好吧，这个想法非常简单：构建一个索引，它只包含与条件匹配的行。下面是一个例子：

CREATE INDEX tasks_pending
          ON tasks (status)
       WHERE status = 'Pending'

如果表中有100M条记录，则完整的B树必须对所有100M行进行编目。你需要它来检查主键的唯一性…但它又大又贵。现在假设您的100M记录只有1000行，其中status=pending。你得到的索引只有1000行。小，快，完美。这里的优点是，部分索引不一定随着历史数据集的增长而变大。而且，对历史数据集大声疾呼，当你需要在一个简单的搜索中获得聚合等数据时，它们是非常好的。如果将内容拆分为多个表，则需要使用UNION编写更长的查询。（对于物理分区被逻辑分区主表屏蔽的分区，情况并非如此。）
高温高压