首先介绍一下背景：
表A作为ta
表 B 为 tb
一个“ta”可以拥有多个“tb”，但一个“tb”只能由一个“ta”拥有。
我经常只是在“tb”上添加一个指向“ta”的 FK，然后就完成了。现在我愿意以不同的方式对其进行建模（以提高其可读性）；我想使用一个连接表，将其命名为“ta_tb”并将 PK 设置为“tb_id”，以强制执行“一对多”子句。
尽管采用了方法a，但使用方法b时是否存在任何性能问题？
如果这是一个明确的 1:n 关系（并且永远如此！），则不需要（也没有优势）在两者之间添加新表。
您将使用这样的连接表来构建 m:n 关系。
使用具有 1:n 关系的连接表可能只有一个原因：如果您想管理指定此关系详细信息的其他数据。
每当您规范化数据库时，性能总会受到影响。如果您执行连接表（或有时称为交叉引用），则 dbms 将需要执行连接正确记录的工作。
如今，DBMS 在创建索引和减少这些性能影响方面做得非常好。这只是取决于你的情况。
可读性和规范化哪个更重要？然后使用连接/外部参照表。
这适用于您想要表现良好的小型应用程序吗？只需让表 B 与其父表具有 FK 即可。
如果索引正确，对性能的影响应该很小，尽管会产生非常轻微的额外成本，除非您的数据库已经达到极限，否则可能不会注意到。
但是，如果您这样做并希望保持 b 列中的每个 id 必须有一个且仅有 1 个 a 的想法，那么您需要确保在连接表中的表 b 的 id 上放置唯一索引。稍后，如果您需要将其更改为多对多关系，您可以删除索引，这肯定比更改数据库结构更容易。 否则，这种设计会使您的数据完整性面临风险。
因此，如果我知道最终可以实现多对多关系，那么联接表可能是我推荐的结构。否则，我可能会坚持使用表 b 中 FK 的更简单结构。
是的，至少您需要再进行一次连接来访问 TableB 字段，这会影响性能。 （这里有一个与此相关的问题数据库连接何时以及为什么昂贵？）
此外，使用联接表的关系被称为多对多，在您的情况下，您在中间表上有一个 PK“使”该关系成为一对多，这比方法 A 的可读性较差。
尽可能保持简单，方法 A 非常适合一对多关系。