我在一家管理多种出版物的公司工作。可能 15-20种不同类型的出版物，有点简化它们都包含文档（pdf）和多个不同的属性，即某些类型有作者，有些有其他类型的作者，有些可能有到目前为止，这些类型都有自己的架构，并且它们都有自己的java Web应用程序连接到这个架构。
但现在已经选择使用以下数据库架构：
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通过视图（由Schema X拥有）访问模式X中的公共部分。在这里，webapp A永远不会看到与架构X中其他webapps相关的出版物。特定于webapp的表将进入架构A，B，C等。
以上只是为了说明，随着时间的推移会有很多webapps。在Schema X中，可能有50个表。
当webapp A需要创建/更新实体时，它也会通过视图发生，这意味着我们可能只为webapp A 100而不是触发器。
新架构的原因是：一切只保存在一个地方，扩展公用表会更容易，导出出版物会更容易。
我对数据库设计没有太多经验，但对我来说，所选择的解决方案似乎是试图实现某种继承。我们在模式X中有公共部分，在其他模式中有专门的部分。我看到有几种方法可以实现继承，例如here，但我认为我们的解决方案不同，因为它似乎适用于模式级别。
所以问题是：有没有人有类似的经历？赞成还是反对？也许这甚至是一种完全正常的数据库设计方式？
对我来说，作为一名java开发人员，它似乎非常复杂。即使只是向实体添加单个属性也很复杂。从我对它的少量经验来看，看起来非常模糊和难以跟踪数据流层次，更不用说找出失败时的错误。
对于这是一个好的模式还是一个反模式，以及可能是另一个更简单的解决方案，我真的很感激。
答案 0 :(得分：1)
在不了解您的情景的情况下，提供积极的建议真的很难。我同意它似乎过于复杂（模式X中有50个表??）但是可能有充分的理由。也很难理解为什么你仍然需要在各个模式中使用表格。
我建议一件事：如果你有Oracle Enterprise Edition，请查看行级安全性。 VPD可以为您提供所需的数据分离，而且复杂性更低。 Find out more。
“对你而言，它不是标准架子上的设计”
目前很少有数据库设计来自Planet Standard。但是，如果你有一万张桌子，那么你甚至不在同一个太阳系中。这是一张荒谬的桌子。
答案 1 :(得分：1)
不同类型的出版物听起来像是类型和子类型的经典案例，或者，如果您愿意，还可以是类和子类。标准SQL没有继承机制，但问题很好理解。它之前已被看过数千次。
看看以下标签：
single-table-inheritance class-table-inheritance shared-primary-key
问题，答案和标签wiki将帮助您使用通用解决方案，您可以定制其中一种解决方案以满足您的需求。您可以点击“了解更多”来查看标签维基。
共享主键不是关于继承。它是关于强制实施一对一关系，这种关系在一端是可选的。