Я понимаю, что в Django ORM не поддерживает тип ENUM в MySQL или PostgreSQL, поскольку это изначально было расширением MySQL, а не переносимым по другим типам БД. Таким образом, два варианта - использовать аргумент "выбор" для вашей модели или использовать ссылку на внешний ключ.
Каковы плюсы и минусы этих подходов?
Что-то вроде пола, я предполагаю, что вы будете использовать "выборы", например:
GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)
...
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
Однако, для чего-то вроде имен состояний, в чем причина и против использования отдельной таблицы и внешних ключей к этой таблице?
state = models.ForeignKey(AustralianState)
В каких обстоятельствах вы могли бы использовать один против другого?
Cheers, Виктор
Вы также должны учитывать внешние ключи, когда количество потенциальных вариантов велико. Это одна из причин рассмотрения использования FK для стран или государств. В противном случае вы эффективно кодируете большое количество данных в исходном коде.
Я бы использовал варианты, в которых выбор не менялся со временем. Если бы они были, FK с новой моделью был бы лучше.
Я бы порекомендовал использовать таблицы поиска по умолчанию, иначе вы сохраняете данные в своем коде. Это также делает значения поиска доступными для пользователей, которые обращаются к базе данных напрямую, а не через ваше приложение (например, функции BI/создания отчетов).
Заметное исключение - где я бы использовал выбор вместо таблицы поиска - это объект поиска, значения которого контролируют логику на уровне кода. Это часто встречается у сущностей "status" или "type" (например, BillingType), где логика зависит от значения поля "type". В этих случаях код обычно ссылается на явные идентификаторы (коды) этих типов, и добавление нового типа потребует логических изменений (в коде) в любом случае.