&引用；“继承”；Oracle数据库中的模式级

我在一家管理几类出版物的公司工作。可能有15-20种不同类型的出版物，稍微简化一下，它们都由一个文档（pdf）和多个不同的属性组成，即有些类型有作者，有些类型有其他类型的作者，有些可能有物理维度等。到目前为止，这些类型都有自己的模式，他们都有自己的JavaWeb应用程序连接到这个模式

但现在选择使用以下数据库体系结构：

    Webapp A                           Webapp B                      Webapp C
        |                                 |                              |
        ▼                                 ▼                              ▼
Schema A (for type A)           Schema B (for type B)          Schema C (for type C)
        |                                 |                              |
        |                                 |                              |
        ▼                                 ▼                              ▼
------------------------------------------------------------------------------------
|                                                                                  |
|                           SCHEMA X (COMMON PARTS/TABLES)                         |
|                                                                                  |
------------------------------------------------------------------------------------

公共部分转到模式X。Webapp A通过模式A连接，模式A通过视图（由模式X所有）访问模式X中的公共部分。在这里，webapp A永远看不到与模式X中的其他webapp相关的发布。webapp特定的表将进入模式A、B、C等

以上只是为了说明，随着时间的推移，将会有很多网络应用。在模式X中，可能有50个表

当webapp A需要创建/更新实体时，它也会通过视图进行，这意味着我们可能有100个触发器，而不仅仅是webapp A

新体系结构的原因是：所有内容都只保存在一个地方，扩展公共表会更容易，导出发布也会更容易

我在数据库设计方面没有太多经验，但对我来说，选择的解决方案似乎是试图实现某种继承。我们在模式X中有公共部分，在其他模式中有专门部分。例如，我看到有几种实现继承的方法，但我认为我们的解决方案是不同的，因为它似乎在模式级别工作

所以问题是：有没有人有过类似的经历？赞成还是反对？也许这是做数据库设计的一种完全正常的方式

对我来说，作为一名java开发人员，这似乎非常复杂。即使只是向实体添加一个属性也很复杂。从我对它的少量经验来看，它看起来非常模糊，很难沿着数据流向下分层，更不用说找出它失败时的错误了

---

我非常感谢大家对这是一个好模式还是一个反模式的看法，以及可能的另一个更简单的解决方案

如果不进一步了解你的情况，就很难给出积极的建议。我同意这似乎过于复杂（模式X中有50个表！），但这可能有很好的原因。也很难理解为什么在各个模式中仍然需要表

我建议您做一件事：如果您有Oracle Enterprise Edition，请检查行级安全性。虚拟专用数据库（VPD）可以为您提供所需的数据分离，而复杂性大大降低

---

“对你来说，这不是标准架上的设计”

---

如今，很少有数据库设计符合行星标准。但是如果你有一万张桌子，那么你甚至不在同一个太阳系。那张桌子的数目太多了

不同类型的发布听起来像是类型和子类型的经典案例，或者，如果您愿意，类和子类的经典案例。标准SQL没有继承机制，但问题已经很清楚了。它以前已经被见过几千次了

请查看以下标签：

这些问题、答案和TagWiki将为您提供一个通用解决方案，您可以定制其中一个解决方案以满足您的需求。您可以通过单击“了解更多”来查看标记wiki

---

共享主键本身与继承无关。这是关于强制执行一对一的关系，这在一端是可选的。

非常感谢Walter，我会调查的。对于通过视图发生的所有交互，您有什么看法？我当然可以看到它有它的位置，但让它成为不可避免的规范对我来说似乎有点沉重（尤其是更新）。这只是我的观点，但我倾向于使用视图进行查询，而不是更新。在糟糕的过去，通过视图进行更新的限制比必须的更严格，这使我的想法有偏差。