MultiSelectField в сравнении с отдельной моделью
Я создаю каталог больниц и клиник и в качестве поля специальности хотел бы хранить специальность или тип клиники или больницы (например, дерматолог и т.д.). Однако, есть некоторые места, особенно крупные, с большим количеством различных специальностей в одном месте, и поскольку метод choices= в CharField не позволяет выбрать более одного варианта, мне пришлось придумать альтернативу.
Сначала я не думал, что нужно создавать отдельную таблицу и добавлять отношение, поэтому я попробовал пакет django-multiselectfield и он прекрасно работает, но я подумал, не лучше ли создать другую таблицу и дать ей отношение к модели Hospitals. Эта таблица 'type' или 'speciality', созданная однажды, скорее всего, никогда не изменит своего содержимого. Будет ли лучше создать другую таблицу с точки зрения производительности?
Также я пытаюсь хранить choices модели в другом choices.py файле с TextChoices классами моделей, так как я буду использовать одни и те же варианты выбора в различных полях разных моделей в разных приложениях. Я знаю, что обычно лучше хранить варианты внутри одного класса, но имеет ли это смысл в моем случае?
Производительность, вероятно, не является здесь главной проблемой; я думаю, что разница между двумя подходами будет незначительной. Вопрос о том, будет ли одна или несколько моделей использовать один и тот же набор вариантов выбора, не склоняется в ту или иную сторону; это можно сделать либо с помощью фиксированного списка, либо с помощью отношения "многие ко многим".
Хотя вы говорите, что выбор не изменится (аргумент в пользу жестко заданного списка выбора), медицинские специальности - это вид данных, которые меняются в долгосрочной перспективе. В отличие от, скажем, месяцев года или дней недели, вероятность изменения которых гораздо ниже.
<<<Однако, если у вас уже есть поле с множественным выбором, я бы склонялся к тому, чтобы оставить его в покое, пока не появится убедительная причина изменить его.
Что касается второй части, я не вижу проблем с хранением списка вариантов в другом .py файле. Я сделал это исключительно для того, чтобы мой models.py выглядел несколько красиво - я не хочу прокручивать 150 вариантов, чтобы дважды проверить метод модели.
Первая часть - это дело вкуса. Я бы лично пошел по пути Relation + Many-To-Many.
Я всегда планирую крайние случаи, так что "скорее всего не изменится" = "значит, есть вероятность"
.
Также мне нравится, что маршрут Relation + Many-To-Many не имеет зависимостей, это основная функция Django... Это довольно надежно и перспективно
.
Дополнительным преимуществом является то, что создание еще одной таблицы также означает, что нетехнический человек может потенциально добавить новые опции, и теоретически вы не тратите свое время на постоянные изменения.