我一直遇到这个设计问题，到目前为止我对我的解决方案并不满意。问题是这样的：
我有两个或多个实体，例如 People 和 Dogs，它们都与 Notes 表有关系，该表存储消息字段和有关消息的一些元数据，例如作者。
1）第一个选项是不强制执行外键。这样，我可以将诸如 peopleId 或 dogId（无论它是什么）之类的 FK 存储在与 fkId 相同的通用 FK 字段中。然后我将 tableId 存储在另一列中——希望从 RDMS 元数据中获取表 id，但你也可能有一个肮脏的 hack 并明确地制作一个充满你必须手动更新的表的表. 这真的很草率，我只是为了完整性而提到它。
2) 为每个需要它的表克隆 Notes 表，例如 PeopleNotes、DogNotes、CatNotes 等。这会产生一个相当大的规范化问题。
其他人在这种情况下做了什么？
如果这些是您的“模型”表：
dog Table:
id | name | ...
1 | Rex
2 | Fido
people Table:
id | name | ...
1 | Bob
2 | Alice
notes Table:
id | text | ...
1 | A nice dog.
2 | A bad dog.
3 | A nice person.
您可以将关系保存在单独的表中：
dog_note Table:
dog_id | note_id
1 | 1
2 | 2
note_people Table:
person_id | note_id
1 | 3
2 | 3
我通常坚持使用模型的字母顺序来命名关系表的约定。
两个新表——Dog2Notes 和 People2Notes 怎么样？Dogs、People 和 Notes 都是具有相互关联的 Key 的实体。Dogs 和 People 可以拥有多个便笺，并且可以共享便笺。
如果 Dogs 和 People 每个只能有一个注释，那么在每个表中添加一个 NOteID？
我更喜欢将便笺的所有者存储在两列中，一列用于 ID，一列用于类/表。
这真的取决于你如何查询你的数据，但是这样的事情怎么样，假设每个人/狗有多个笔记：
人员表
PeopleID
NoteID
.....
狗桌
DogID
NoteID
...
笔记表
NoteID
NoteDetailTable
NoteDetailID
NoteID
NoteText
...
难道不是比目前建议的更好的解决方案是拥有一个主 id 表吗？
dog Table:
id | name | masterId
1 | Rex | 1
2 | Fido | 4
people Table:
id | name | masterId
1 | Bob | 2
2 | Alice| 3
masterId
id
1
2
3
4
notes
id | note | masterId
1 | "Hi" | 3
2 | "Good day" | 2
这将使可伸缩性更容易，因为如果您需要添加新的实体类型（例如 cat），则不需要添加另一个表（cat_note），如果您添加新的笔记类型（例如书籍）特别有用，因为那时您需要为所有实体类型（person_book、dog_book 等）添加新表。最后，您可以直接将任何实体表与注释表相关联。
The only "issue" would be you would need to have a procedure run that would automatically add a new record to the masterId table when a new record is added to an entity table and associate it with the new entry.
P.S. I Know this answer is like nine months after the fact. Just happened upon this while doing other research and thought I put my own two cents in.