数据库设计 - 两个项目应该共享同一个表吗？

Question

背景：
两个项目（A & B）在设计时同时需要一个新表（称为DocumentStore）来存放文件/文件在postgres下。

但周围的文档存储业务逻辑是项目中的& B之间的不同，这意味着约DocumentStore关系是A & B.

之间的不同让我们把这个有点更具体，见下面的例子：

文档存储表结构看起来是相同的，而不限制/外键：

表DocumentStore

DocUUID //unique Id for this document, PK, FK to other table depends on project 
fileName //file name 
fileType //file type 
FileContent //store file as blog 

在项目一个，DocumentStore.DocUUID引用Email.EmailUUID：

注意是有一个电子邮件之间一对多的关系 - 通过FK> DocumentStore。

表Email

EmailUUID //PK 
subject 
title 
... 

在项目乙，DocumentStore.DocUUID引用Letter.LetterUUID：

注意是有一个字母之间一对多的关系 - 通过FK> DocumentStore。

表Letter

LetterUUID //PK 
UserId 
rightId 
... 

Email和Letter是因为业务逻辑的不同完全不同。

---

我的问题是：

1. 我应该分享项目之间的这种DocumentStore表格中的& B'

2. 如果1.的答案是肯定的，那么如何？通过postgres继承？

3. 如果1.的答案为否，我应该创建两个具有相同结构但不同表名和不同外键的表吗？一个用于项目A和项目B？

Answer 1

只有其中一个fk约束对表的同一个实例的每列有效。你将不得不为每个fk添加一列。或者有两个documentstore表。

当你澄清，同一行中documentstore属于字母或电子邮件，但只有那些的单一个，而每个字母/电子邮件可以有多个文件。
因此，我的新建议：坚持你现在有的表设计，但创建两个独立的表。把他们放在同一张桌子里没有任何好处。两个表共享相同结构的事实是没有很好的理由来共享数据。

您罐有schema_a.documentstore和schema_b.documentstore继承自master.documentstore。如果您的用例同时处理两个表中的所有行，那么这将非常有用。一定要阅读关于limitations of inheritance in Postgres的章节。特别是，它不会让你定义一个FK约束：

继承特性的一个严重的局限性是索引 （包括唯一约束）和外键约束只适用 单表，而不是给他们的继承儿童。 在外键约束的引用和引用方都是如此。

相关答案与代码示例：
Find out which schema based on table values
Create a table of two types in PostgreSQL

Answer 2

同桌是罚款。那么你有一些选择 - 如果你需要在同一张桌子内部进行区分 - 你可能会添加一个'类型'列 - 我认为你并不需要它，或者你建立关联类到其他东西，例如：

Doc_email 
---------- 
DocUUID 
EmailUUID 

和

Doc_letter 
----------- 
DocUUID 
LetterUUID