我的问题是关于将两个连接表合并为一个的想法，对于类似的相关表。请看我的意思。还请注意，这确实是我面临的一个问题，因此与本论坛有关。这只是一个具有广泛影响的话题，我希望能吸引更多专业人士的参与，以便更好地对“最佳实践”进行普查，如果你愿意的话。
我有一个相当有挑战性的数据库设计问题。我希望这将是一种维基，许多人可以贡献和学习。为了更简单，我创建了一组图形，并将问题分解为1）过程和2）结构。
工艺步骤
对文档（发布）提出请求（docrequest）。
如果所述出版物不存在，则创建新发布。
保存运行日志（statusreport）以了解执行请求的进度。
注意：对于任何给定的发布，可能有许多docrequest和statusreports（包括更新）
数据库结构
注意：docrequest和statusreport表都有许多字段和支持表，这些字段和支持表没有显示在所附的图形中。此外，特定出版物是这些表中所有记录所属的主记录。
--当前实施--
注意：此设计的主要缺陷是，无论何时创建新的docrequest和statusreport记录，都必须在publications表（其作用类似于连接表）中创建新记录，但这也会因此创建新的发布。这不是我们想要的行为。
--典型实现--（对于这种类型的关系）
注意：这是可以的，而且可能是理想的，但是处理docrequest和statusreport表的更新，将它们独立链接到它们所属的发布。
--我的首选实现--（对于这个特殊情况）
注：我在这里的想法，只是把双连接表合并成一个。在这种情况下，连接表将在docrequest或statusreport发生插入时获取新记录。我可能会用扳机来处理这件事。
讨论
现在开始讨论。我想从我的数据库开发同事那里知道，如果你认为这是一个坏主意，以及由此可能产生的问题。我认为记录的净数量应该与两个独立的连接表相同，并且通过保存一个额外的id列，实际上使用的空间稍微少一些。：）
告诉我你们的想法。我真的很想让很多人参与这次讨论。干杯！：）
最佳答案
我认为你用连接表来思考是在伤害你自己。想想桌子。
由于statusreport与文档请求的状态有关，
你需要一张能把这两者联系起来的桌子。
“statusreport”对于存储文档请求状态的事实的表来说是一个糟糕的名称。
对于任何表中的任何列，“id”都是一个糟糕的名称。
发布的ID号似乎更多地与文档请求有关，而不是与请求的状态有关。（你说，如果一个新的出版物不存在的话，就会创建一个新的出版物。”坦率地说，这是一个滑稽的边缘。
参考您首选的实现图，我将删除表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)
);