Les sous-requêtes Sqlite : dans une seule grande requête ou dans une boucle for ?

Question

Je prévoyais de faire des tests de performance mais comme c'est beaucoup de travail, j'aimerais vérifier si je n'ai pas oublié de réponse évidente avant.

J'ai une requête énorme qui récupère quelques détails supplémentaires pour chaque ligne avec une sous-requête.

Chaque ligne est ensuite utilisée dans un ListAdapter qui est branché dans un ListView, donc une autre boucle prend chaque ligne une par une pour en faire un ListItem.

Qu'est-ce que vous pensez est plus efficace :

• Garder les sous-requêtes dans le fouillis SQL, en comptant sur le moteur SQL pour optimiser.
• Retirer les sous-requêtes dans la boucle ListAdapter, donc on charge les détails paresseusement à l'affichage : beaucoup plus lisible mais j'ai peur que trop de demandes ralentissent le processus.

Deux choses importantes :

• Je ne peux pas réécrire le gros morceau SQL pour me débarrasser des sous-requêtes. Je sais que ce serait mieux, mais j'ai échoué à le faire.
• Pour autant que je sache, une liste ne contiendra pas plus de 1000 éléments, et c'est une application de bureau donc il n'y a pas de concurrence. Est-ce même pertinent de se soucier des performances dans ce cas ? Si non, je serais quand même intéressé par la réponse pour un site web à fort trafic. C'est bon de savoir...

Answer 1

SQLite est un moteur très performant, mais il ne s'agit pas vraiment d'optimisations très astucieuses, et je ne le considérerais pas vraiment pour un "site web à fort trafic". Un gros avantage (pour les utilisations dans ses limites) est qu'il peut s'exécuter en interne, de sorte que les frais généraux de requêtes multiples sont vraiment minimes comparés à une grosse requête ; si c'est plus facile à coder pour votre cas d'utilisation spécifique, je le considérerais vraiment (et le faire de manière "lazy load", comme vous l'indiquez, pourrait en fait rendre les premières données de l'écran plus rapides à apparaître !). Comme vous le soupçonnez, il est peu probable que cela soit un goulot d'étranglement en termes de performances dans votre cas d'utilisation, donc opter pour un codage plus simple et donc plus fiable est un avantage important.

Si je devais créer un site à fort trafic et utiliser un moteur plus riche et plus lourd comme PosgtreSQL, Oracle, SQL Server ou DB2, je ferais beaucoup plus confiance à l'optimiseur. Une chose que j'ai remarquée, cependant, est que je peux souvent (hélas, pas toujours) transformer les sous-requêtes en jointures, et cela tend souvent à améliorer les performances (les jointures facilitent l'utilisation de bons index pour l'optimiseur, je pense - je n'ai jamais codé un optimiseur SQL moi-même, mais c'est mon impression en regardant les plans d'exécution de requêtes de nombreux moteurs pour des formes alternatives de requêtes... cela suppose bien sûr que vous avez de bons index !-) - cela devrait être confirmé avec un test de performance du cas spécifique en question, bien sûr, mais ce serait mon hypothèse de travail initiale.

Answer 2

Que diriez-vous d'utiliser des curseurs?

Je préférerais utiliser une grande requête et laisser mon moteur SQL optimiser ma requête. Je ne peux pas non plus penser à un exemple où il vaut mieux faire une boucle en dehors de SQL au lieu d'utiliser une requête "grosse" ou des curseurs.

Mais le meilleur moyen de savoir ce qui est mieux est de le tester.

Bonne chance!