web-dev-qa-db-ja.com

Djangoクエリ-id vs pk

Django=クエリを記述するとき、クエリパラメータとしてid/pkの両方を使用できます。

Object.objects.get(id=1)
Object.objects.get(pk=1)

Djangoのドキュメントによると、pkは主キーの略であり、単なるショートカットであることがわかっています。ただし、idまたはpkをいつ使用するかは明確ではありません。

djangoormprimary-key
180
Art

関係ありません。 pkは実際の主キーフィールドからより独立しています。つまり、主キーフィールドがidまたはobject_idなどと呼ばれるかどうかを気にする必要はありません。

また、異なる主キーフィールドを持つモデルがある場合、より一貫性が得られます。

196
Felix Kling

In Django私がpkが常にidを返すことを知っているプロジェクトでは、id()関数（変数名を除くすべての場所）と衝突しない場合はidを使用することを好みます。 pkは、idでpk属性名を検索するのに時間がかかるため、metaよりも7倍遅いプロパティです。

_%timeit obj.id
46 ns ± 0.187 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
%timeit obj.pk
347 ns ± 11.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
_

関連するDjangoコード：

_def _get_pk_val(self, meta=None):
    meta = meta or self._meta
    return getattr(self, meta.pk.attname)

def _set_pk_val(self, value):
    return setattr(self, self._meta.pk.attname, value)

pk = property(_get_pk_val, _set_pk_val)
_

pkという名前の変数を使用する必要があるのは、本当にまれなケースです。 pkの代わりに_user_id_のような、より冗長なものを使用することを好みます。

プロジェクト全体で同じ規則に従うことが望ましいです。あなたの場合、idはプロパティではなくパラメータ名であるため、タイミングにほとんど違いはありません。パラメーター名は、組み込みのid()関数の名前と衝突しないため、ここでidを使用しても安全です。

要約すると、フィールド名idを使用するか、pkショートカットを使用するかを選択するのはユーザー次第です。 Django=のライブラリを開発しておらず、すべてのモデルで 自動主キーフィールド を使用している場合は、idをどこでも安全に使用できます。一方、（おそらくカスタムの）主キーフィールドへのユニバーサルアクセスが必要な場合は、あらゆる場所でpkを使用します。

12
utapyngo