对另一个模式中的表的外键引用答案

【问题标题】：Foreign key reference to table in another schema对另一个模式中的表的外键引用
【发布时间】：2011-01-06 21:44:35
【问题描述】：

我试图在我的一个表上创建外键，引用不同架构中的表列。

类似的东西：

ALTER TABLE my_schema.my_table ADD (
  CONSTRAINT my_fk
    FOREIGN KEY (my_id)
    REFERENCES other_schema.other_table(other_id)
)

因为我有必要的资助，所以效果很好。

现在我想知道是否有不引用不同架构中的表的原因，或者有什么需要注意的？

【问题讨论】：

标签： sql oracle database-design

【解决方案1】：

这样做没问题。在表之间建立外键关系时，模式确实没有影响。只需确保相关人员拥有您打算使用的架构所需的权限。

【讨论】：

【解决方案2】：

如果您所在的组织中不同的人对不同的架构拥有权限，我认为最好让其他架构能够禁用，甚至删除并重新创建您的约束。

例如，他们可能需要删除或截断他们的表，然后重新加载它以处理一些（非常奇怪的）支持问题。除非您想在半夜接到电话，否则我建议让他们能够暂时删除您的约束。（我还建议您设置自己的警报，以便您知道是否有任何外部约束被禁用或丢弃）。当你跨越组织/模式界限时，你想与他人相处融洽。文森特提到的指数是其中的另一部分。

【讨论】：

【解决方案3】：

这将完全作为引用其自己架构中的表的外键。

与常规外键一样，如果父键已更新或从父表中删除条目，请不要忘记索引my_id（未索引的外键可能是大规模争用的来源，并且索引通常是反正有用）。

【讨论】：

【解决方案4】：

我遇到的唯一问题是确保权限存在于另一个架构上。通常的东西 - 如果这些权限由于某种原因而消失，你会听到的。

【讨论】：

【解决方案5】：

这可能导致问题的一个原因是您需要小心以正确的顺序删除内容。这可能是好是坏，取决于表中永远不会出现孤儿的重要性。

【讨论】：

好吧，但是在我的模式中引用表时也是如此。对吗？
是的，是一样的。不过，这是需要小心的事情