Да, NullBoolean
подходит, но если есть дополнительные параметры, которые не соответствуют профилю NullBoolean
, я за IntegerField
за удобочитаемость и согласованность параметров.
Null
может интуитивно означать n/a
, но, поскольку вы добавляете больше вопросов с одним выбором, я думаю, что еще более интуитивно понятно использовать IntegerField
, сопоставленный со статическими переменными.
Также для сценариев такого типа, гдепользователь, вероятно, отфильтрует свойства, основываясь на этих функциях. Полезно не использовать специальный регистр Null в динамическом запросе.
Пример:
...filter(Q(nearby_school__isnull=True) | Q(nearby_school='NO')),
other_choice='SOME_CHOICE')
# vs
...filter(Q(nearby_school=Feature.NOT_SURE) | Q(nearby_school=Feature.NO)),
other_choice=Feature.SOME_CHOICE)
Этот древний пост до сих пор служит отличнымссылка: http://www.b -list.org / weblog / 2007 / nov / 02 / handle-choices-right-way /
class Feature(models.Model):
YES = 0
NO = 1
NOT_SURE = 2
SOMETIMES = 3
YES_CHOICES = (
(YES, 'Yes'),
(NO, 'No'),
(NOT_SURE, 'Not Sure'),
(SOMETIMES, 'Sometimes'), # extensible.
)
Что касается поля с множественным выбором, я делаюдумаю, что использование поля m2m - самый простой / лучший способ.
Вы можете настроить forms.MultipleChoiceField
для хранения данных в виде поля, разделенного запятыми, и отображения соответствующим образом, но тот факт, что вы можете легко запросить поле m2m, является огромным преимуществом + он работает прямо из коробки сModelMultipleChoiceField
.