数据库表，一张表引用多个不相关的表

Question

在我的搜索过程中，这个问题在各个论坛中出现过几次，但没有一个提供简洁的解决方案。

如果我有以下表格：

User
+- id
+- username
+- password

Article
+- id
+- title
+- content

并且我想加入它们以确定谁创建了哪些文章，我可以简单地将 user_id 列添加到 Article 中以用作参考。或者，我添加一个中间表来显示谁/何时/什么，例如：

User
+- ...

Article
+- ...

ChangeHistory
+- id
+- article_id
+- user_id
+- type [enum(insert, update, delete)]
+- datetime

现在这很好，但我正在开发的系统需要更加动态，因为可以轻松引入和集成新模块。因此，现在如果我添加 Media 表，我需要将 ChangeHistory 拆分为 Article 和 Media ，其中

User
+- ...

Article
+- ...

Media
+- id
+- title
+- path

ArticleChangeHistory
+- id
+- article_id
+- user_id
+- type [enum(insert, update, delete)]
+- datetime

MediaChangeHistory
+- id
+- media_id
+- user_id
+- type [enum(insert, update, delete)]
+- datetime

：随着许多模块的引入，很快就会失控。每个模块都需要负责创建和管理它自己的 ChangeHistory 表。

TL;DR：我可以探索哪些实践来创建可以接收对多个其他不相关表的引用的中间表？我可以添加一个 *record_type* 字段，保存记录所属表的名称，但这很丑陋。我需要类似“表 ID”之类的东西来引用它所来自的表。这样，当/如果添加或删除模块时，模型就不会崩溃。

有什么想法吗？预先非常感谢。

Answer 1

根据我的经验，当开发人员试图使他们的系统真正“动态”时，他们实际上是在尝试为他们尚未想到的问题编写代码。这通常是一条不好的路。对于一个模块来说，包含两个表而不是一个表真的需要做很多额外的工作吗？

在我见过的每种情况下，尝试制作一个通用的“做所有事情”的表格的模式（或反模式？），它都失败了。 RDBMS 在明确定义的问题领域中效果最佳。如果模块需要保留历史记录，那么模块应该添加一个历史表以与表本身一起使用。这还有一个巨大的优势，因为以后您可能希望根据保存历史记录的表或模块在历史记录中保留不同类型的信息。如果您有一个通用的历史表，那就变得更加困难。

现在，如果您想简单地捕获最后一个用户更新或插入特定项目（表行）并且该项目可能位于多个表中，那么您可以使用具有父表和多个子表的继承模式。例如：

CREATE TABLE Audited_Items
(
    id    INT    NOT NULL    IDENTITY,
    CONSTRAINT PK_Audited_Items PRIMARY KEY CLUSTERED (id)
)
CREATE TABLE Articles
(
    id    INT            NOT NULL,
    [Article specific columns]
    CONSTRAINT PK_Articles PRIMARY KEY CLUSTERED (id),
    CONSTRAINT FK_Articles_Audited_Items FOREIGN KEY (id) REFERENCES Audited_Items (id)
)
CREATE TABLE Media
(
    id    INT            NOT NULL,
    [Media specific columns]
    CONSTRAINT PK_Media PRIMARY KEY CLUSTERED (id),
    CONSTRAINT FK_Media_Audited_Items FOREIGN KEY (id) REFERENCES Audited_Items (id)
)
CREATE TABLE Audit_Trail
(
    audited_item_id    INT         NOT NULL,
    audit_datetime     DATETIME    NOT NULL,
    user_id            INT         NOT NULL,
    [audit columns]
    CONSTRAINT PK_Audit_Trail PRIMARY KEY CLUSTERED (audited_item_id, audit_datetime),
    CONSTRAINT FK_Audit_Trail_Audited_Items FOREIGN KEY (audited_item_id) REFERENCES Audited_Items (id)
)

Answer 2

在我看来，你似乎在寻求一位向导来引导你走上一条曲折、布满荆棘的道路。

我不知道为什么每次获得新的“模块”时都需要添加一个新表（我不清楚模块是什么），只要这些模块都可以用相同的列布局来描述。您可以添加一个 Modules 表，然后在 Articles 表中包含一个 ModuleId 列。

此外，文章可以有多个作者，因此如果您的作者有，则需要一个 ArticleAuthors 表。在某些圈子里，文章的作者顺序很重要。这是对他们的贡献的重要性或他们在该领域的重要性的排名。如果是这种情况，您需要有一个“序数”列来反映作者的立场。

Answer 3

我认为您可能最好使用一个类似于以下内容的 ChangeHistory 表：

ItemChangeHistory
+- id
+- changedItem_id
+- user_id
+- changedItemType_id
+- type [enum(insert, update, delete)]
+- datetime

然后使用 changedItemType_id 来根据 changedItemType_id 找出更改的内容（例如文章、媒体等...）代码>itemType表。这样，您只有一张表来存储所有内容更改历史记录，并且在添加/删除模块时无需添加/删除表，只需更新 itemType 表即可。当然，这意味着删除模块必须小心 - 您可以留下引用该模块类型的 ItemChangeHistory 记录（但这很混乱）或删除与该模块关联的所有历史记录。

---

现在您提到一个模块可能有其他表，所以也许需要使用子模块 ID 来跟踪这些表，也在 ItemChangeHistory 中引用？

Answer 4

为什么不呢

ChangeHistory
+- id
+- content_id
+- content_type
+- user_id
+- action [enum(added, updated, deleted)]
+- datetime

Answer 5

@马吉德：
我知道这可能是最合理的解决方案，但我希望找到一些更直观的东西，一些可以利用现有数据库参数的东西；例如难以捉摸（并且显然不存在）的表 id（我的意思是引擎（在我的例子中为 InnoDB）用来描述表的某种内部引用）

@frustrated：
我想我会接受类似的事情。我会继续调查可能性。