Database design - should two projects share the same table?

Question

Background:
Two projects (A & B) under design at the same time both needs a new table(called DocumentStore) to store document/file under postgres.

But business logic around the document storage are different between project A & B, this means relationship around DocumentStore are different between A & B.

Let's make this a bit more concrete, see example below:

The Document storage table structure looks the same without constraints/ foreign Keys:

Table 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

In project A, DocumentStore.DocUUID references Email.EmailUUID:

Note there is a one to many relationship between Email -> DocumentStore via the FK.

Table Email

EmailUUID //PK
subject
title
...

In project B, DocumentStore.DocUUID references Letter.LetterUUID:

Note there is a one to many relationship between Letter -> DocumentStore via the FK.

Table Letter

LetterUUID //PK
UserId
rightId
...

Email and Letter are completely different because of different of business logic.

---

My questions are:

1. Should I share this DocumentStore table between project A & B ?

2. If the answer to 1. is yes, then how? Through inheritance under postgres?

3. If the answer to 1. is no, should I create two table with the same structure but different table name and different foreign key ? One for project A and project B?

Answer 1

Only one of those fk constraints works per column of the same instance of the table. You would have to add one column for each fk. Or have two documentstore tables.

As you clarified, the same row in documentstore belongs to either a letter or an email, but only to a single one of those, while each letter / email can have multiple documents.
Hence my new advice: stick with table design you have now, but create two separate tables. There is no gain in having them in the same table. The fact that both tables share the same structure is no good reason to share the data.

You can have schema_a.documentstore and schema_b.documentstore inheriting from master.documentstore. That would mainly be useful if you have use cases dealing with all rows in both tables at once. Be sure to read the chapter about limitations of inheritance in Postgres. In particular, it won't allow you to define a single fk constraint:

A serious limitation of the inheritance feature is that indexes (including unique constraints) and foreign key constraints only apply to single tables, not to their inheritance children. This is true on both the referencing and referenced sides of a foreign key constraint.

Related answers with code examples:
Find out which schema based on table values
Create a table of two types in PostgreSQL

Answer 2

same table is fine. then you have some choice - you may add a 'type' column if you need to differntiate inside the same table - which i think you don't really need or you build associative classes to the other things like this:

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

and

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