我有可能潜在引用的四种不同的表一个唯一标识符的列。 我已经看到了两种方式完成这件事，但两者似乎是不好的做法。
首先，我见过一个ObjectID列没有明确声明它作为一个外键特定的表。 然后，你可以推你在它想要的任何唯一标识符。 这意味着你可能会从不属于4个表，我想中的表中插入的ID。
其次，因为数据可以来自四个不同的表，我也看到了人们做出4个不同的外键。 而在此过程中，该系统依赖于一体的，具有非NULL值只有一列。
什么是这样做的更好的方法？ 举例来说，在我的表中的记录可能会参考医院（ID），诊所（ID），学校（ID），或大学（ID）......但只有那些表。
谢谢！
你可能要考虑一个类型/子类型的数据模型。 这是非常像面向对象编程类/子类，但更尴尬的实现，并没有RDBMS（据我所知）的原生支持他们。 总体思路是：
你已经注意到这个模型的问题，对不对？ 什么是保持从具有条目的建设在两个或两个以上的子类型的表？ 很高兴你问：
瞧：给定一个BUILDING行类型H，在学校表中的条目（与类型S）设定不能被设置为引用该建筑
你会记得，我没有说这是很难实现的。
事实上，最大的问题是：这是值得做的事情？ 如果是有意义的执行四个（或更多，随着时间的流逝）的建筑类型为类型/子类型（进一步正常化的优点：一个地方地址和通用按建筑物其他属性，与存储在子表特定于建筑物的属性），它可能是值得额外的努力来建立和维护。 如果没有，那么你又回到原点：这是很难的逻辑模型在现代平均RDBMS实现。
让我们开始在概念层面。 如果我们认为医院，诊所，学校，大学为主题的实体类，有没有概括全部的超？ 有可能是。 我不会试图告诉你它是什么，因为我不明白你的主题，以及你做的。 但是，我要继续，好像我们可以把所有这些“制度”，并把四个为机构的子类。
至于其他的反应已经指出，类/子类扩展和继承不是建立在多数的关系数据库系统。 但是有很多的帮助，如果你知道正确的流行语。 接下来打算教你的流行语，在数据库的行话。 这里是未来的流行语的总结：“ER泛化”，“急诊室的专业化”，“单表继承”，“班表继承”，“共享主键”。
在概念层次上停留，ER建模是在概念层面理解数据的好办法。 在ER建模，有一个概念，“ER泛化”，和对方概念“ER专业化”平行思维过程我上面提出的“超/子”。 ER专业化告诉你如何来图的子类，但它并没有告诉你如何实现它们。
接下来我们从概念层面到逻辑电平下移。 我们表示数据关系方面，或者如果你愿意，SQL表。 有一对夫妇的实现子类技术。 一个被称为“单表继承”。 另一种是所谓的“类表继承”。 与类表继承连接，还有另一种技术，该技术由名称“共享主键”去。
你的情况与类表继承展望未来，我们首先设计了一个名为“机构”表中，带有ID字段名称字段，以及所有涉及到机构领域，无论它们是四种。 比如像邮寄地址字段，例如。 同样，你了解你的数据比我好，你可以发现，在现有的表中的所有四个字段。 我们填充以通常的方式id字段。
接下来，我们设计的四个表称为“医院”，“诊所”，“学校”和“大学”。 这些将包含一个id字段，以及所有仅属于那种机构的数据字段。 比如，一家医院可能有“产床”。 同样，你了解你的数据比我好，你可以从你现有的表中的字段未使其进入机构表图这些了。
这是“共享主键”进来。当一个新条目被制作成“制度”，我们必须做出新的并行进入的四个专业子类表之一。 但是，我们不使用某种形式的自动编号功能来填充id字段。 相反，我们把id字段的副本从“制度”表到子类的表的ID字段。
这是一个小的工作，但好处是非常值得的努力。 共享主键强制执行的子类条目和超类项之间的关系的一对一的性质。 它使加入超数据和子类数据的简单，方便，快捷。 它省去了一个特殊的领域，告诉您哪些子类特定机构的所属。
而且，你的情况，它提供了一个方便回答你原来的问题。 你最初询问外键是现在总是一个外键机构表。 而且，由于共享主键的魔力，外键也引用了相应的子表中的条目，没有额外的工作。
您可以创建与四个子类表的结合机构数据，为方便起见，四个视图。
查一查“ER专业化”，在网络上“班表继承”，“共享主键”，也许“单表继承”，并在这里SO。 有大多数的在这里等等这些概念或技术的标签。
你可以把桌子上的触发器，并强制执行引用完整性那里。 我不认为有一个非常好的外的现成功能来实现这一要求。
