W projektach Django, o których wiem, że pk
zawsze zwraca id
, wolę używać, id
gdy nie koliduje z id()
funkcją (wszędzie oprócz nazw zmiennych). Wynika to z tego, że pk
jest to właściwość 7 razy wolniejsza niż id
czasochłonne wyszukiwanie pk
nazwy atrybutu meta
.
%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)
Oto odpowiedni kod 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)
To naprawdę rzadki przypadek, kiedy muszę użyć zmiennej o nazwie pk
. Wolę używać czegoś bardziej szczegółowego, jak user_id
zamiast pk
.
Przestrzeganie tej samej konwencji jest preferowane w całym projekcie. W twoim przypadku id
jest to nazwa parametru, a nie właściwość, więc prawie nie ma różnicy w taktowaniu. Nazwy parametrów nie kolidują z nazwą wbudowanej id()
funkcji, więc można z niej bezpiecznie korzystać id
.
Podsumowując, od Ciebie zależy, czy chcesz użyć nazwy pola, id
czy pk
skrótu. Jeśli nie tworzysz biblioteki dla Django i używasz automatycznych pól klucza podstawowego dla wszystkich modeli, możesz bezpiecznie używać id
wszędzie, co czasami jest szybsze. Z drugiej strony, jeśli chcesz mieć uniwersalny dostęp do (prawdopodobnie niestandardowych) pól klucza głównego, używaj go pk
wszędzie. Jedna trzecia mikrosekundy to nic dla sieci.
id
i zapk