то есть основной вопрос при построении программных продуктов - это "как правильно хранить данные", на самом-то деле)

order_by("field") если перед field указать тире будет нисходящий порядок

а когда происходят изменения, связанные с этим - вот тут и начинается всякий гемор) поэтому лучше изначально потратить время и хорошо спроектировать) чем потом 100 раз это менять) чем меньше всяких миграций структуры и данных - тем проще жить

можете, пожалуйста, разъяснить как работает связка nginx-uwsgi-django. как мне видится принцип работы всего этого дела: nginx делает из обычного сервера веб-сервер, готовый принимать запросы извне. но сам nginx передать запрос конкретному приложению (django), не может, поэтому ставиться еще одна прослойка в виде uwsgi. uwsgi по аналогии с селери (если такая аналогия вообще возможна) запускает несколько воркеров, в каждом из которых крутится приложение джанги.
и правильно ли я понимаю, что при каждом новом запросе с клиента, по сути создается новый объект application’a (который я указываю в wsgi.py), содержащий в себе все приложение джанго проекта ?

подскажите пожалуйста , как называеться этот метод который в админке , можно добавить сразу по 3-4 поля для модели

Нет

Форма?

Честно не помню , когда-то делал , что можно не 1 полю добавлять , а  сколько угодно

Инлайн ты имеешь ввиду что ли?

во ,да

Как сделать взаимный unique для нескольких полей ?

а как тогда? хотя бы на пальцах

вообще, лучше идти от задачи к реализации, а не под реализацию подбирать задачу

nginx в указанной выше связке во многих проектах вообще не участвует, его там нет

например, есть связка CloudFlare -> контейнер с uWSGI (+Python/Django и прочее) + S3 для статики, в которой nginx'а вообще нет [он там есть, но пользователь с ним напрямую не взаимодействует]

extra

то есть если в моем приложении почти нет статики (большинство ответов от django в формате json'a, либо в HttpResponse прикладывается excel файл), то nginx-то и не нужен, можно все настроить с использованием одного лишь uwsgi ?

nginx обычно используется или как прокси или балансировщик или для раздачи статики) и то и другое в общем-то может делать и uWSGI, но у nginx'а получится лучше) но это будет не важно, если сверху стоит CDN типа CloudFlare

nginx может присутствовать как прокси уровня сервера или кластера, например, принимать запросы и передавать их в тот или иной контейнер) но это больше к администраторам вопрос, чем к программистам)

если статики нет, а есть только API, то главное преимущество nginx'а - хорошая раздача статики - не является актуальным... nginx всё равно может иметь ряд преимуществ, например, при интеграции с CloudFlare nginx может проверять, что запрос пришёл именно от CloudFlare и отвечать только на такие запросы