13
Rozumiem, że w Django ORM nie obsługuje typu ENUM w MySQL lub PostgreSQL, ponieważ był to pierwotnie rozszerzenie MySQL i nie jest przenośny w innych typach DB. Więc dwie opcje to użycie argumentu "choice" dla twojego modelu lub użycie referencji klucza obcego.Model Django - wybory kontra klucz obcy?
Jakie są plusy i minusy tych metod?
Na coś takiego jak płeć, zakładam, że używasz „wybory”, np:
GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)
...
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
jednak na coś takiego stanu nazwy, jakie są powodem i przed użyciem oddzielnego stołu i kluczy obcych do tego stołu?
state = models.ForeignKey(AustralianState)
W jakich okolicznościach używałbyś jeden kontra drugi?
Cheers, Victor
Czy to ze względu na wydajność? Hmm, więc dla wielu stanów, przypuszczam, że tablica wyników FK jest drogą do zrobienia? A następnie po prostu listę stanów w urządzeniach Django? – victorhooi
To nie tyle powody, dla których wydajność jest lepsza z krotkami, chyba że szukasz więcej niż kilka tysięcy opcji - to głównie problem z konserwacją. W rzeczywistości Django ma wiele pól kraju/stanu wbudowanych w ustawienia regionalne, jak sądzę. I przypuszczam, że mógłbyś stworzyć StateField, który zaimportowałeś do innych plików. Pełne ujawnienie: jestem pewien, że pola kraju i stanu, których używam w niektórych częściach moich aplikacji, faktycznie wykorzystują wybory. Ale FK również byłby dobrym wyborem. –
Dodałbym, że w tym przypadku użycie skrótu kraju i stanu jako klucza obcego, zamiast zwiększania liczby całkowitej, ma dużo większy sens. –