复杂的数据库关系（联结表）

Question

我的问题是关于将两个联结表合并为一个的想法，用于类似相关的表。请阅读以了解我的意思。另请注意，这确实是我面临的一个问题，因此与这个论坛有关。这只是一个具有广泛影响的话题，我希望能引起各专业人士的更多参与，以便对“最佳实践”进行更好的普查。

我有一个相当具有挑战性的数据库设计问题。我希望这将是一个许多人可以贡献和学习的维基。为了让这更容易，我创建了一组图形，并将问题分解为 1) 过程和 2) 结构。

流程步骤

1. 已提出文档（出版物）请求 (DocRequest)。
2. 如果该出版物尚不存在，则会创建一个新出版物。
3. 会保留运行日志 (StatusReport) 以了解完成请求的进度。

注意：对于任何给定的出版物，可能有许多 DocRequests 和 StatusReports（包括更新）

数据库结构

注意：DocRequest 和 StatusReport 表都有许多字段和支持表，未在附图中显示。此外，特定的 Publication 是这些表中所有记录所属的主记录。

--当前实施--

注意：这种设计的主要缺陷是，每当您创建新的 DocRequest 和 StatusReport 记录时，您还必须在 Publications 表（其作用类似于联结表）中创建一个新记录，但这结果还创建了一个新的出版物。这不是我们想要的行为。

--典型实现--（对于这种类型的关系）

注意：这没问题，并且可能是理想的，但会处理对 DocRequest 和 StatusReport 表的更新，将它们独立链接到它们所属的出版物。

--我的首选实现-- （对于这种特殊情况）

注意：我在这里的想法只是将双联结表合并为一个。在这种情况下，只要 DocRequest 或 StatusReport 发生插入，联结表就会获得一条新记录。我可能会用触发器来处理这个问题。

讨论

现在开始讨论。如果您认为这是一个坏主意，我想从我的数据库开发人员那里知道，以及由此可能产生的问题。我认为记录的净数应该与两个单独的联结表相同，实际上通过节省额外的 ID 列来使用更少的空间。 :)

让我知道你们的想法。我真的很想让很多人参与这个讨论。干杯! :)

Answer 1

我认为您考虑连接表是在伤害自己。想想表格吧。

• 由于 StatusReport 与文档请求的状态有关， 您需要一张以某种方式将这两个联系起来的表格。
• “StatusReport”对于存储有关文档请求状态的事实的表来说是一个糟糕的名称。
• “ID”对于任何表中的任何列来说都是一个糟糕的名称。
• 发布的 id 号似乎与文档请求有关，而不是与请求的状态有关。 （你说，“如果说出版物不存在，则创建一个新出版物。”坦率地说，这已经接近了没有意义的边缘。）所以出版物编号几乎肯定属于 DocRequest 表。

参考您首选实现的图表，我将删除表 TripleJunction，并将 StatusReport 替换为此。

-- Predicate: Document request number (doc_request_id) has status (status) 
--            as of date and time (status_as_of).
create table document_request_status (
  doc_request_id integer not null references DocRequest (id),
  status_as_of timestamp not null default current_timestamp,
  status varchar(10) not null,
  -- other columns go here
  primary key (doc_request_id, status_as_of)
);