外键是否可以使用常量而不是字段名称？将FK与STI子类相关联

Question

建立

因此,一旦您决定使用STI(单表继承),我发现这种情况相当普遍.

你有一些基本类型与各种子类型.

• 人<(教师,学生,工作人员等)
• 用户<(会员,管理员)
• 会员<(买方,卖方)
• 车辆<(汽车,船,飞机)
• 等等

在数据库中建模有两种主要方法:

• 单表继承
  • 一个带有类型字段和一堆可空字段的大表
• 类表继承
  • 每种类型一个表,共享PK(从孩子到父母的FK)

虽然STI存在一些问题,但我确实喜欢它如何设法减少你必须加入的连接数,以及像Rails这样的框架中的一些支持,但是我遇到了一个关于如何关联的问题子类特定的表.

例如:

• 认证应仅参考教师人员
• 配置文件应仅引用成员用户
• WingInformation应该与汽车或船只无关(除非你是蝙蝠侠)
• 广告由卖方 - 会员而非买方 - 会员拥有

使用CTI,这些关系是微不足道的 - 只需在相关表上打一个外键即可完成:

ALTER TABLE advertisements
 ADD FOREIGN KEY (seller_id) REFERENCES sellers (id)

但是对于STI,类似的事情不会捕获子类型限制.

ALTER TABLE advertisements
  ADD FOREIGN KEY (seller_id) REFERENCES members (id)

我希望看到的是:

* Does not work in most (all?) databases *
ALTER TABLE advertisements
  ADD FOREIGN KEY (seller_id, 'seller') REFERENCES members (id, type)

我能找到的只是一个脏的黑客,需要在相关的表中添加一个计算列:

ALTER TABLE advertisements
  ADD seller_type VARCHAR(20) NOT NULL DEFAULT 'seller'
ALTER TABLE advertisements
  FOREIGN KEY (seller_id, seller-type) REFERENCES members (id, type)

这让我觉得奇怪(更不用说不优雅了).

真正的问题

有没有RDBMS可以让我这样做？

有没有理由说这甚至不可能？

除了在最微不足道的情况下,这只是为什么不使用STI的另一个原因？

Answer 1

没有标准方法可以在外键声明中声明常量。您必须命名列。

但是您可以使用以下方法之一强制该列具有固定值：

• 计算列

• 检查约束

• 在 INSERT/UPDATE 之前触发，以使用默认值覆盖任何用户提供的值。