Интересно излагаете.
У меня была похожая проблема и мой хороший друг посоветовал делать больше вещей спонтанно, а не пытаться их проанализировать.
Мой воздушный плюс вам.
Я надеюсь вы прочитали моё послесловие? Я использую данный подход не на том примере, что описывается в статье. Код я специально облегчил, чтобы не вводить в заблуждение. Именно поэтому я не стал называть статью «Делаем теги в django» или «Реализация поля город в django». Модели нейтральны, главное — множественный выбор с функцией автокомплита.
Да, вопрос быстродействия меня тоже волнует и пока что я не определился как лучше. Мельком посмотрел метки на хабре, вроде бы подгружаются по мере ввода пользователем.
И опять же с какой стороны посмотреть, базу городов мы хотя бы примерно можем оценить по объему. А если использовать структуру, бесконечно расширяющуюся, такую как метки на хабрахабр. Не станет ли в определенный момент объем меток критичен для быстродействия?
С городами и странами да. Можно подойти с двух сторон: ManyToManyField — одна страна принадлежит множеству городов, ForeignKey — один город принадлежит одной стране.
С другой стороны, если нам необходима связка моделей City и Profile, к примеру, когда пользователь может указать множество городов, в которых он был. Или, как я написал в самом конце, данный подход можно использовать для реализации тегов, когда один тег принадлежит множеству сообщений. В этом подходе ForeignKey уже не подойдет.
Или же вариант, если модель City нам необходимо использовать не только для связки с таблицей Country, но и с другими таблицами. В этом подходе хочется, чтобы модель City была максимально независима от остальной логики проекта.
Пока что никак не отслеживаем, потому что проект еще не закончен. На начальном этапе, наверное, будем вручную все модифицировать, а дальше будет видно.
У меня была похожая проблема и мой хороший друг посоветовал делать больше вещей спонтанно, а не пытаться их проанализировать.
Мой воздушный плюс вам.
И опять же с какой стороны посмотреть, базу городов мы хотя бы примерно можем оценить по объему. А если использовать структуру, бесконечно расширяющуюся, такую как метки на хабрахабр. Не станет ли в определенный момент объем меток критичен для быстродействия?
С другой стороны, если нам необходима связка моделей City и Profile, к примеру, когда пользователь может указать множество городов, в которых он был. Или, как я написал в самом конце, данный подход можно использовать для реализации тегов, когда один тег принадлежит множеству сообщений. В этом подходе ForeignKey уже не подойдет.
Или же вариант, если модель City нам необходимо использовать не только для связки с таблицей Country, но и с другими таблицами. В этом подходе хочется, чтобы модель City была максимально независима от остальной логики проекта.
Сначала испугался, не так понял.