La requête de pagination est un problème souvent rencontré. Examinons d'abord la raison pour laquelle la requête de pagination existe :
Commodité pour l'utilisateur : il est impossible pour les utilisateurs de visualiser toutes les données en même temps, il est donc préférable de parcourir page par page.
Améliorer les performances : la récupération simultanée de toutes les données de la base de données sera plus lente.
Alors maintenant, permettez-moi d’essayer de réfuter les raisons ci-dessus :
est-ce vraiment pratique ? Nous considérons la situation suivante s’il n’y a que 20 données.
Si les données dépassent 1 000 éléments.
Le premier type ne nécessite évidemment pas de requêtes de pagination. Ce qui est étrange, c'est que le second n'est pas nécessaire, car aucun utilisateur n'est disposé à parcourir page par page jusqu'à la fin. Si les données interrogées par l'utilisateur dépassent la plage de données qui l'intéresse, je pense qu'il devrait être autorisé à les saisir à nouveau. les conditions de requête, tout comme nous. Identique à l'utilisation de Google.
Mais en tant qu'interface d'application conviviale, nous espérons toujours que l'utilisateur pourra pleinement comprendre les résultats de sa requête. Il est donc nécessaire de dire à l'utilisateur : "Combien de données avez-vous trouvées ? Cependant, actuellement, seuls les 1 000 premiers éléments peuvent être affichés. Si vous souhaitez afficher toutes les données, alors que faut-il faire..."
Les performances s’amélioreront-elles ?
Si la quantité de données est faible, les performances ne seront évidemment pas améliorées de manière significative, au contraire, les performances seront considérablement réduites. Parce que la base de données effectue des requêtes et des conditions de requête inutiles.
Si la quantité de données est importante, les performances peuvent ne pas être améliorées de manière significative, car vous devez toujours exécuter une requête de comptage supplémentaire, et lors de la combinaison de SQL, cela entraînera très probablement une analyse complète de la table. Bien entendu, cela dépend du principe de mise en œuvre de la base de données.
On peut imaginer que la relation entre l'impact des requêtes de pagination sur les performances et la quantité de données devrait être une courbe. Lorsque la quantité de données est faible, les performances seront réduites, et lorsque la quantité de données est importante, les performances. peut (en fonction des différentes bases de données) être amélioré. La clé est de trouver le point d’inflexion de la courbe grâce à des tests. Les performances ne sont pas obtenues sur la base de l'expérience et du ressenti, mais grâce à des tests. De plus, si toutes les données sont supprimées en même temps, cela affectera effectivement les performances de l'espace. Cependant, la mémoire est très bon marché maintenant...
Impact négatif Pour une application web bien architecturée, il est vraiment inconfortable de passer pageNo et PageSize entre différentes classes. Ces deux données appartiennent évidemment à la couche de présentation. Bien sûr, si vous utilisez RoR, je n’en ai pas parlé.
Augmente considérablement la complexité de la programmation, en particulier si l'on considère l'indépendance de la base de données.
Phénomène étrange : pourquoi une grande base de données ne fournit-elle pas directement des requêtes de pagination ? Le RowNo d'Oracle n'est pas utilisé pour la pagination, pas plus que le Top de SQLServer.
en conclusion
ExtremeTable, DisplayTag et JSF DataTable fournissent tous des méthodes de pagination simples, c'est-à-dire la pagination dans la collection de résultats. Il est très pratique à utiliser et rend la logique claire, ce qui améliore considérablement l'efficacité du travail. Dans la plupart des cas, cette méthode peut être utilisée directement.
Si vous constatez grâce à des tests que la méthode ci-dessus affecte les performances, envisagez d'utiliser des requêtes de pagination.
Pour les applications comportant un grand nombre d'utilisateurs, les requêtes de pagination peuvent également être envisagées en raison de contraintes de mémoire. Cependant, je recommande personnellement la méthode du cache : la même requête est placée dans un cache...
Utilisez une conception raisonnable pour empêcher les développeurs de gérer la logique de pagination. Par exemple, la logique de pagination et la requête de comptage sont placées dans la classe parent et le développeur est responsable de la combinaison des conditions de requête. Examinons spécifiquement les modèles de conception.
Tout le monde est invité à discuter ! ! !