私はpkとそれらがどのように機能するかについて興味がありました。Djangoは、すべてのモデルの主キーを自動インクリメント整数フィールドに自動的に設定しますが、これは通常、効率の点で最良のオプションですか？
pkを増分整数のままにしておくと、カスタムを作成するよりも害が大きくなるシナリオは何ですか？そして、人々が通常使用するカスタムpkは何ですか？
編集：最後の質問です。以前のプロジェクトのほとんどでは、URLで主キーをgetパラメーターとして公に使用していました。例：website.com/1234/ここで、1234はクエリされたモデルのpk'id'です。これは悪い設計と見なされますか、それともこれを共通化していますか？
ありがとう！
主キーは、テーブル内のデータ用の特別なタイプのインデックスです。主キーの制約の1つは、それが一意でなければならないということです。where句の主キーを使用してルックアップを実行すると、そのデータの取得は非常に高速になります。
クエリが主キーを使用してルックアップを実行したり、主キーに基づいてそのデータを別のテーブルと結合したりしない場合、自動インクリメントの主キーを使用してもあまり意味がありません。この場合、それは単に無駄なインデックスであり、テーブル内の他の列の主キーを使用する方がよいでしょう（一意の制約を満たすことができる場合）。自動インクリメントのpkeyを使用しても意味がなく、一意のインデックスも使用できない場合は、pkeyを使用せずにテーブルを作成し、フェッチ、更新、または削除するときに常に最も効率的なインデックスを使用するようにしてください。単一のレコード。
pkeyを自動インクリメント整数として残すことが、良いことよりも害を及ぼす可能性がある理由は考えられません。使用されていない場合にのみスペースを浪費し、無関係になります。 コメントで指摘されているように、データにアクセスするために必要な情報がpkeyだけである場合、シーケンシャル主キーによって情報が公開されたり、特定のソーシャルエンジニアリング攻撃に対して脆弱になる可能性があります。
複合インデックスを主キーとして使用する場合は、カスタム主キーを使用できます。別のインスタンスは、すべてが一意のシリアル番号を持つアイテムを追跡するテーブルである可能性があります。この場合、シリアル番号も一意であり、ほとんどのルックアップまたは検索で使用される可能性があるため、自動インクリメントIDの代わりにシリアル番号をpkeyとして使用できます。