Question

背景：
同时设计的两个项目（A＆amp; B）都需要一个新表（称为DocumentStore）来存储postgres下的文档/文件。

但是项目A和A之间的文档存储的业务逻辑是不同的。 B，这意味着A {和}之间DocumentStore左右的关系不同。乙

让我们更具体一点，见下面的例子：

文档存储表结构看起来没有约束/外键：

表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

在项目 A 中，DocumentStore.DocUUID引用Email.EmailUUID：

请注意，电子邮件与＆gt;之间存在一对多的关系。 DocumentStore通过FK。

表Email

EmailUUID //PK
subject
title
...

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

请注意，Letter之间存在一对多的关系 - ＆gt; DocumentStore通过FK。

表Letter

LetterUUID //PK
UserId
rightId
...

由于业务逻辑不同，

Email和Letter完全不同。

我的问题是：

我应该在项目A＆amp;之间共享这个DocumentStore表吗？ B？
如果对1.的回答是肯定的，那么如何？通过postgres下的继承？
如果1.的答案为否，我应该创建两个具有相同结构但不同的表名和不同外键的表吗？一个用于项目A和项目B？

Answer 1

这些fk约束中只有一个适用于表的同一实例的每列。您必须为每个fk添加一列。或者有两个documentstore表。

正如您澄清的那样，documentstore中的同一行属于字母或电子邮件，但只属于单个其中一行，而每封信/电子邮件可能包含多个文档。
因此，我的新建议：坚持使用现在的表格设计，但创建两个单独的表格。将它们放在同一张桌子上没有任何好处。两个表共享相同结构的事实没有充分的理由来共享数据。

可以<{1}}继承schema_a.documentstore schema_b.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

同桌很好。然后你有一些选择 - 你可以添加一个＆＃39;类型＆＃39;如果您需要在同一个表中区分 - 我认为您并不真正需要，或者您将关联类构建到其他类似的东西：

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

和

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

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

2 个答案: