对于大型应用程序，在同一个数据库的不同模式的表上创建外键是个坏主意吗？

13

我正在将基于pl / sql网络的大型应用程序传输到专用服务器。此应用程序位于具有70个程序包代码的模式中。在不同的时间大约有15个人进行了此应用程序。对我们来说，通常的做法是在不同模式的引用表上创建外键，因为它确实很方便并且可以使数据库保持整洁，因为我们不需要在不同的模式中保留相同的引用表。

但是无论如何，我的DBA（使用DB创建新实例并在Solaris区域内复制我的应用程序）今天非常苛刻，“不同模式上的外键是邪恶的，您需要销毁它！”。他没有解释他的观点。

在大型应用程序上这样做真的是个坏主意吗？

oracle database-design schema foreign-key

— 亚历山大·米肖夫
source

13

您的DBA应该被解雇。

— Colin't Hart 2013年

1

如果他们这么说，我们都会大声疾呼您的DBA是白痴，但是您确定DBA的论点没有其他背景吗？

— 柯米特（Kermit）2013年

1

也许DBA尽了最大的努力来支持开发人员在构建此事物时所做的荒谬工作。

— swasheck 2013年

2

@swasheck另一方面，您是否想在数据库累积了该DBA多年的不一致之后找到他的工作？

— 2013年

@Twinkles根本没有

— swasheck 2013年

6

忍受我-我来自SQL Server，讨厌oracle，但我认为争论仍然存在。

模式可以很好地将表与逻辑子系统隔离。外键可确保数据完整性。这些是正交的概念-显然子系统之间的数据完整性也是必须的。会计和运输以及可能的中央客户数据都不存在于筒仓中，在使用客户时，客户可能会被删除。

因此，我认为DBA的要求是无能的标志。请任何人都可以介入并提出反对意见-我会很高兴。但是，这就是我在SQL Server上执行的操作（尽管，同样，我们对架构的定义是IIRC与oracle定义不同的一点）。

— 汤姆汤姆
source

4

虽然要求在没有详细推理的情况下销毁外键约束是愚蠢的，但使外部引用受到控制是有意义的。如果您引用的模式在新服务器上的命名不同，该怎么办？

在Oracle中，您可以通过为当前架构之外的对象创建SYNONYMS来解决此问题。

— 一闪
source

1

您可能会过度使用同义词，并使“这指的是什么？”这个问题更加混乱。有关安全性，性能和最佳做法的更多详细信息，请参见此处stackoverflow.com/a/10042117/851930

— kevinsky 2013年

3

同义词不能用作外键约束的目标。

— Colin't Hart 2013年

有效点。进一步的证据表明，在没有给别人机会争论优缺点的情况下发表声明是不好的。

— 2013年

2

如果需要（空间/安全性/其他）将任何模式移至其他数据库，则将无法再处理引用。这可能是请求终止引用的主要原因。

— AMG
source

0

我可以从中想到的唯一“坏主意”是，您不能授予角色一个REFERENCES对象特权（创建引用表的约束所需的特权）。我必须按架构/用户完成架构/用户。

除此之外，我看不到您的DBA的意义。

— Vegatripy
source

0

只需考虑一下：子表所有者模式开始在其表中创建记录，并且在不知不觉中阻止了父表模式用户从父表中删除记录。它期待和赞赏吗？

— letron123
source