复杂数据库关系（连接表）

Question

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

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

流程步骤

1. 提供文档（发布）的请求（DocRequest）。
2. 如果该出版物尚不存在，则会创建新出版物。
3. 保持正在运行的日志（StatusReport）以完成请求。

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

数据库结构

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

- 当前实施 -

注意：此设计的主要缺陷是，无论何时创建新的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)
);