Вопрос о вложенных наборах в эффективности Django и запроса
Попробуйте это:
for i, item in enumerate(marketId_list):
if i>0 and marketId_list[i] != marketId_list[i-1]:
test()
2 ответа
Это очень хороший вопрос, и он не ограничивается рамками Django ORM.
Я всегда чувствую, что важно помнить некоторые проблемы, которые решает инфраструктура объектно-реляционного отображения (ORM):
объектно-ориентированный CRUD : если остальная часть приложения основана на строгих объектно-ориентированных принципах, доступ к постоянству данных использование объектов делает код намного более связным, внутренне непротиворечивым и иногда более коротким.
Инкапсуляция персистентного уровня : ORM обеспечивает прозрачный уровень в вашем приложении для доступа к БД. Он включает в себя все функции, необходимые для чтения / записи данных в одном месте, воплощение так называемого принципа СУХОЙ (не повторяйся). Это делает несколько вещей намного проще: изменения модели , потому что весь код выбора и вставки / обновления, обращенный к БД, находится в одном месте, а не во всем приложении, безопасность , потому что весь доступ к БД проходит через одно местоположение, и тестирование , потому что это легко смоделировать ваши модели данных и получить доступ к ним, если они четко очерчены.
Безопасность SQL : Несмотря на то, что легко защитить использование необработанного SQL от атак с использованием инъекций и т. п., еще проще, если у вас есть единая среда ORM как единое целое. точка DB-контакта, которая делает это за вас, поэтому вам никогда не придется об этом думать.
Обратите внимание, что скорости нет в списке. ORM - это уровень косвенности между вашим кодом и базой данных. Мы, конечно, считаем, что разработчики ORM ответственны за написание среды, которая производит хорошие операторы SQL, но ORM предназначен для обеспечения эффективности на уровне кода и архитектуры, не исполнительная эффективность. Разработчик, прочитавший основную книгу по SQL, всегда сможет добиться большей производительности, общаясь напрямую с БД.
Конечно, есть стратегии противодействия этому, и в Django это select_related () как Озан упомянул и кэширование сайта / представления / разного, но они не дадут вам такой же производительности, как прямой оператор SQL. Из-за этого я никогда не использовал бы среду ORM, которая не предоставляет некоторый механизм для выдачи необработанного оператора SQL в тех случаях, когда мне нужна скорость. Например, я часто прибегаю к необработанному SQL при создании большого отчета из базы данных, который объединяет множество таблиц; Путь ORM может занимать минуты, способ SQL - секунды.
Сказав это, я никогда не начинаю с беспокойства по поводу каждого отдельного запроса. Мой совет для всех, кто приходит на уровень ORM: не няня доступа к базе данных ORM. Напишите свое приложение или модуль, а затем профилируйте его, настраивая те области, которые действительно нуждаются в повышении производительности, или используя caching / select_related для уменьшения общей болтливости БД вашего приложения.
Вы можете использовать метод набора запросов select_related () , чтобы уменьшить количество запросов к базе данных. Вы также можете указать глубину, поэтому в данном примере, если модель телефонного номера имела дополнительные внешние связи, вы бы использовали select_related (deep = 2), чтобы избежать выбора дополнительных «уровней» связанных объектов.