ORM: запросы, связи, лишние обращения

«В учебном списке 20 книг, у каждой один автор; сериализатор читает его имя. В логе одна выборка книг и двадцать обращений за авторами. Предложи вариант для указанной версии Django и тест роста списка до 40». Приложите модель и сериализатор: без них нельзя выбрать способ загрузки только по названию поля author.

Нет, решение зависит от связи и формы результата. Для нескольких коллекций соединение может размножить строки, а предзагрузка отдельными запросами — сохранить удобную структуру объектов. Попросите оценить не только количество обращений, но и переданные строки, память и пагинацию. Один огромный запрос не обязательно дешевле нескольких ограниченных запросов с понятным набором полей для конкретного экрана.

Сравните идентификаторы объектов, сортировку и связанные значения до и после правки. Добавьте книгу без необязательной связи и автора с несколькими книгами. Проверьте количество запросов при сериализации, а не только при построении queryset: ленивая загрузка может произойти позже. Измерения проводите на одинаковых данных и учитывайте прогретые кэши, которые способны скрыть лишние обращения к базе.

Она может разобрать предоставленный код и объяснить вероятную форму SQL, но фактический запрос лучше взять из вашего лога. Укажите ORM, драйвер и версии: имена методов и поведение загрузки различаются. Не передавайте строки с реальными персональными значениями. Если план выполнения отсутствует, рекомендации об индексе остаются предположением до проверки на вашей схеме и данных.