Sql 多对多关系的替代方案

假设我有两张桌子——书和作者。一本书可以有许多作者，一个作者可以有许多书，这意味着他们处于多对多关系中，我需要第三个表来实现这一点

我真的想避免这种情况，因为我是一个初学者，这使得查询对我来说更加复杂

所以我的问题是：除了多对多之外，实现这种关系的最佳方式是什么

我想在每个表中放一个外键，这样我的books表中就有一个authoridFK，authors表中就有一个bookIdFK。但我不确定那会是什么类型的关系，这对我是否正确，以及它在ERD上的表现如何

---

有人能给我澄清一下吗？

最好的，也是最标准的方法是使用第三张表来维持这种关系

至于查询复杂性，您可以研究在查询中使用

JOIN

，也可以获得一个ORM来处理这些类型的关系

给定上下文的示例联接查询将返回所有作者及其贡献的所有书籍的列表，如下所示：

select a.AuthorName, b.BookName 
from author a
  join AuthorBookMapping m on m.AuthorID = a.AuthorID
  join Book b on m.BookID = b.BookID

---

中间表是建立关系的唯一正确方法。 这种逻辑不会使结构复杂化，但相反，它允许遵守良好实践：

• 每个数据项必须位于数据库中唯一的位置
• 每个记录（对象）必须具有唯一的主键

通过这种方式，您既可以将作者链接到他们的书籍，也可以将多个作者指定给同一本书，当然，也可以将多本书指定给同一作者

高级CRUD系统还允许您在图书列表中显示作者并编辑这些关系

这里有一个

---

它解释了关于直接/间接关系和识别/非识别关系的主要内容

作为一个初学者，为什么不尝试正确地实施它并一路学习呢？正如您最初提到的，正确的方法是在数据库中实现交叉实体。当您需要添加更多的关系数据时，您建议的其他表定义将使您的生活更加困难。正确的方法是您试图避免的方法。三个表：作者、书籍和链接这两个表的关系表。感谢您的回复。你很好，但我想知道这是唯一的办法吗。比如说，我想从第三级降到第二级。那么我该如何实现呢？不要去规范化。不要用错误的方法做。这并没有什么好处。通过在数据库中进行非规范化，您将得到重复的数据，这几乎是不可避免的。这就是以第三范式存储数据的要点，因此您不需要重复的数据实例。我看到的唯一一个非规范化是在某些数据汇总或需要预先计算或计算数据的实例中，例如搜索表。