我可以避免django（python）的MySQL表中出现冗余的主键列吗？

我知道，如果我使用Django的ORM，那么每个表都必须有一个主键列。不知何故，如果您有一个多对多表，它链接到表（让我们称它们为作者和书籍），您将得到如下结果：

id     author_id     book_id
1      1             1
2      1             2
3      2             3
etc.

---

我遇到过一本书，书中建议避免使用“id”列，而是创建一个复合主键。使用django可以吗？

您可以在through表（使用ALTER table）上创建一个复合主键。您还可以从表中删除id列。所有这些都不会对django造成任何伤害，因为许多字段在后端的工作方式都不会使用id列

然而，您应该注意，让复合PK在django中工作基本上是不可能的。这对您来说不应该是一个问题，因为任何表都不应该有指向您的直通表的ForeignKey（至少出于我能想到的任何原因）

---

总之，复合主键不适用于django。因此，如果您需要一个表的ForeignKey和一个复合主键，那么您基本上就是SOL。最后，在这里使用复合主键没有真正的优点，但也没有真正的缺点（在本例中也是唯一的一种情况下）。那你为什么要花时间担心这个问题呢？

我对赞成/反对的论点很感兴趣。文章在哪里？对于链接表，你不需要直接访问它。只需使用Django的ManyToManyField并使用'through'参数指定链接表。请参阅：@sony:I writed article and means book。它的标题是SQL Antipatterns:避免了Bill Karwin编写的数据库编程的陷阱。他指出，如果必须在上面的示例中设置复合唯一约束

author\u id

和

book\u id

。如果这样做，复合键将具有与

id

列相同的属性。因此它变得多余。这篇文章很长，而且里面有更多的参数，但如果我没有弄错的话，我认为这就是它的本质，即：：-，这很好，而且所有的，但他的建议并不适用于django，因为django不支持复合主键。事实上，我认为，一般来说，复合pk是一个坏主意，因为它将您的密钥与您的数据联系起来，使您的pk更宽，并且有各种其他小的负面影响……所有这些都是为了避免重复的唯一性。如果我以后真的有动力，我可能会查阅一些关于不使用复合pk的原因的文章。我只是想了解作者的想法，并扩展我对可行的知识。这里没有发生什么有益的事情。顺便问一下，SOL是什么意思？作者的观点可能是，通过创建冗余的唯一约束，您最终会为此表编写两个索引，而不是一个索引；添加少量写开销。最重要的是，id上的索引可能永远不会被使用。在这种情况下，使用django创建复合pk很可能是安全的，但您不能将此体验扩展到基本上任何其他关系