Erreurs courantes de Django ORM à corriger

Django ORM est l'une des fonctionnalités les plus puissantes de Django. Il élimine une grande partie de la complexité de l'interaction avec les bases de données, permettant aux développeurs de manipuler les données avec la syntaxe Pythonic plutôt qu'avec du SQL brut. Toutes ces fonctions ORM génèrent des requêtes SQL qui peuvent devenir un goulot d'étranglement si elles ne sont pas traitées avec soin.
Ce blog met en évidence les erreurs courantes lors de l'utilisation de Django ORM et propose également des conseils pour que les requêtes restent efficaces, maintenables et performantes.

1. Le problème de requête N 1

Le problème de requête N 1 se produit lorsque votre code déclenche une requête pour récupérer un ensemble d'enregistrements, puis exécute à nouveau N requêtes supplémentaires pour récupérer les données associées.

blogs = Blog.objects.all()    # 1 Query
for blog in blogs:
    print(blog.author.name)   # N additional queries

Dans l'exemple ci-dessus, l'accès à blog.author.name à l'intérieur de la boucle amène Django à récupérer l'enregistrement de l'auteur pour chaque blog individuellement, conduisant à N requêtes supplémentaires.

Comment y remédier
Utilisez select_rated pour des objets associés uniques (par exemple, ForeignKey ou OneToOneField), car il effectue une JOINTURE SQL pour récupérer l'objet principal et ses objets associés en une seule requête. Pour les relations plusieurs-à-plusieurs, plusieurs-à-un ou inverses, utilisez prefetch_rated, qui récupère les données associées dans des requêtes distinctes mais les combine efficacement en Python, évitant ainsi le problème N 1.

# With select_related
blogs = Blog.objects.select_related('author').all()

# With prefetch_related
authors = Author.objects.prefetch_related('blogs').all()

2. Surutilisation de .all() et .filter()

Les développeurs enchaînent souvent plusieurs filtres ou utilisent .all() suivi de requêtes répétées sur le même ensemble de requêtes :

blogs = Blog.objects.all()
active_blogs = blogs.filter(is_archived=False)
popular_blogs = blogs.filter(views__gte=1000)

Bien que Django essaie d'optimiser les ensembles de requêtes en les évaluant paresseusement uniquement lorsque cela est nécessaire, l'appel répété de filtres sur les mêmes données d'ensemble de requêtes peut toujours provoquer des accès inutiles à la base de données.

Comment y remédier
La combinaison de filtres dans une seule instruction permet à Django de générer une seule requête SQL.

popular_active_blogs = Blog.objects.filter(is_archived=False, views__gte=1000)

3. Ne pas profiter de Values() ou de Values_list()

Parfois, nous n'avons besoin que de champs spécifiques plutôt que de toutes les données de champ du modèle. Pendant cela, l'utilisation de .values() ou .values_list() peut être plus efficace.

titles = Blog.objects.values('title')
or
titles = Blog.objects.values_list('title', flat=True)
# values() returns a list of dictionaries.
# values_list() can return tuples or flat values if flat=True is provided.

En récupérant uniquement les colonnes nécessaires, vous réduisez la quantité de données transférées depuis la base de données, améliorant ainsi les performances.

4. Agrégations et annotations inefficaces

Appeler à plusieurs reprises .aggregate() ou .annotate() peut provoquer plusieurs requêtes. Les requêtes complexes avec plusieurs annotations peuvent conduire à des requêtes SQL inefficaces, ce qui peut entraîner des opérations de base de données lourdes.

# Example of multiple aggregate
total_count = Blog.objects.aggregate(Count('id'))
author_count = Blog.objects.aggregate(Count('author'))
average_views = Blog.objects.aggregate(Avg('views'))

Recommandation

blogs = Blog.objects.all()    # 1 Query
for blog in blogs:
    print(blog.author.name)   # N additional queries

5. Ne pas utiliser les index de base de données

L'indexation améliore les performances des requêtes en permettant à la base de données de localiser et de récupérer rapidement les données, évitant ainsi les analyses lentes de tables complètes. Les index optimisent les opérations telles que le filtrage, le tri et la jointure, rendant ainsi les requêtes sur les champs fréquemment consultés beaucoup plus rapides. Un index de base de données manquant sur les champs fréquemment interrogés peut réduire considérablement les performances.
Comment ajouter des index dans Django

# With select_related
blogs = Blog.objects.select_related('author').all()

# With prefetch_related
authors = Author.objects.prefetch_related('blogs').all()

Les index peuvent accélérer la lecture mais ralentir la vitesse d'écriture. Ainsi, n'indexez que les champs que vous devez souvent interroger.

6. Ne pas utiliser la mise en cache

Utilisez la mise en cache lorsque nous devons interroger des données coûteuses à calculer ou qui changent rarement. La mise en cache, même pendant 5 minutes, peut enregistrer des requêtes répétées, des calculs complexes et des requêtes rarement modifiées.

blogs = Blog.objects.all()
active_blogs = blogs.filter(is_archived=False)
popular_blogs = blogs.filter(views__gte=1000)

7. SQL brut

Parfois, l'ORM Django ne peut pas exprimer efficacement une requête complexe ou une opération groupée. Bien que Django propose .extra() ou .raw(), l'utilisation de SQL brut doit être un dernier recours car :

• Perd de nombreux avantages de l'ORM
• Peut conduire à un code illisible ou sujet aux erreurs

S'assurer que les entrées sont correctement nettoyées et que les requêtes SQL brutes restent maintenables.

En appliquant ces conseils, vous améliorerez les performances de votre application Django tout en gardant le code propre et maintenable. Et également suggéré d'utiliser la Django Debug Toolbar dans votre environnement de développement pour surveiller et analyser le nombre de requêtes exécutées, leur temps d'exécution et les instructions SQL.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!