私は事実を知っています、私はDjangoのORMを使用する場合、すべてのテーブルは、主キー列を持っている必要があります。あなたは（のは、作家や書籍、それらを呼びましょう）テーブルにリンクmany_to_manyテーブルを持っている場合はどういうわけか、あなたのようなものになるだろう：MySQLテーブルのdjango（python）の冗長プライマリキー列を避けることはできますか？
id author_id book_id
1 1 1
2 1 2
3 2 3
etc.
を、私は列「ID」を避けるために提案されている書籍に遭遇したと代わりに複合主キーを作成します。これはdjangoでうまくいくのでしょうか？
スルー・テーブルに複合主キーを作成できます（ALTER TABLEを使用）。テーブルからidカラムを削除することもできます。これらのどれも、ManyToManyフィールドがバックエンドでうまく動作していないので、idカラムを使用しないので、途中でdjangoを害することはありません。
しかし、化合物PKをdjangoで動作させることは、基本的には非スターターであることに注意してください。これはあなたのための問題ではありませんあなたのスルーテーブルへのForeignKeyを持っている必要があります（私は少なくとも考えることができる何らかの理由のため。
要約すると複合主キーはdjangoで動作しません。したがって、CompoundKeyを持つテーブルにForeignKeyを設定する必要がある場合は、基本的にSOLです。最後に、Compound PKの使用についての実際のプロはありませんが、実際の詐欺はありません（この場合と唯一のケース）。
私は、著者のアイデアを理解し、その行為者の知識を消費しようとしています。ここでは何も生産的ではありません。ちなみに、* SOL *はどういう意味ですか？ – Aufwind
SOL：http://www.urbandictionary.com/define.php?term=sol – Sonny
そうな著者の引数が冗長一意性制約を作成することによって、あなたは1の代わりにこの表のための2つのインデックスのを書き終わるだろうということでしょう。少量の書き込みオーバーヘッドが追加されます。そして、idのインデックスを上回ることは決して使用されないでしょう。この1つのケースでは、djangoで化合物pkを作成するのが最も安全ですが、この経験を基本的に他の関係に拡張することはできません – John
私は/ againstの引数に興味があります。記事はどこですか？ – Sonny
リンクテーブルについては、直接アクセスする必要はありません.DjangoのManyToManyFieldを使用して、 'through'パラメータを使用したリンクテーブル。参照：https://docs.djangoproject.com/en/dev/topics/db/models/#many-to-many-relatイオンシップ –
@ソニー：私は* article *と* book *を書いた。そのタイトルは、** SQL Antipatterns：** Bill Karwin **によって書かれたデータベースプログラミングの落とし穴を回避することです。彼は、（上記の例では） 'author_id'と' book_id'の上に複合ユニーク制約を置かなければならないと言います。これを行うと、複合キーは 'id'カラムと同じプロパティを持ちます。だから冗長になる。通路は長く、そこにはもっと多くの議論がありますが、私はそれが間違っていなければ、それがその本質であると思います。 :-) – Aufwind