Problèmes de pagination et de tri

Question

Je suis confronté à des situations dans des applications Web orientées base de données dans lesquelles il convient de s’appuyer sur le tri des tables côté client sur le tri côté serveur. Une situation particulière qui me dérange, c'est la pagination.

Lorsque vous essayez de paginer une grande table (par exemple 10000 lignes) et de la trier en fonction d'une colonne particulière, quelle serait la meilleure approche à adopter?

Je comprends que certains problèmes liés à ceci sont:

• Je ne peux pas retourner la table entière du côté client en une fois
• Je ne peux pas trier autant que 10 000 enregistrements avec javascript
• trier le tableau implique le tri des lignes dans toutes les pages, pas seulement la page en cours.

Avez-vous d'autres problèmes à ajouter à cette liste?

Quelle approche permettrait une bonne combinaison d'interactions côté client et côté serveur afin de minimiser la charge du serveur?

ADDITION:

D'accord, trier la base de données et renvoyer la page reqd, une page précédente et une page suivante semblent être le meilleur choix.

Considérons maintenant ceci:

L'utilisateur est à la page (3 sur 10) du tableau, trié par numéro de série. Désormais, l'utilisateur clique sur l'en-tête nommé "nom d'utilisateur", souhaitant trier le tableau par nom d'utilisateur.

Question: le résultat final doit-il être la page (1 sur 10) triée par nom d'utilisateur " ou doit-il être "page (3 sur 10) trié par nom d'utilisateur"?

Je sais que c'est une question très subjective, mais que recommanderiez-vous et pourquoi?

Answer 1

Il est préférable de garder le côté client simple: le tri / la pagination en Javascript s’applique uniquement à de très petits ensembles de résultats - assez petit pour que l’utilisateur ne remarque pas un impact négatif sur les performances.

Le côté serveur est l'endroit où vous pouvez optimiser la charge du serveur:

La charge peut prendre la forme de demandes fréquentes pour plus de pages, d’un grand nombre de lignes / colonnes par page et de demandes fréquentes de recours. (Nous n'avons même pas parlé de filtrage)

Par conséquent, en fonction de vos utilisateurs et de l'utilisation réelle , vous aurez peut-être besoin d'une certaine forme de mise en cache. Notez que ce ne sont que des suggestions APRES que vous sachiez ce que font vos utilisateurs:

• Pour les demandes de page fréquentes, envisagez de faire en sorte que certaines demandes Ajax préchargent les pages suivantes (et précédentes), puis permutez les lignes (via Javascript) dans la table à la demande de l'utilisateur.

• Pour les grandes tailles de page, pensez à conserver les lignes dans la liste "" utilisé le plus récemment". cache d’application (mémoire), afin que la base de données ne soit pas obligée de cracher les mêmes énormes morceaux de données encore et encore.

• Pour les recours fréquents, une bonne approche consiste à conserver une table de cache en SQL avec uniquement les résultats.

Et toujours, toujours, toujours, indexez correctement la base de données.

Réponse supplémentaire:

Ma réponse très subjective est la suivante: l'utilisateur (moi) souhaite effectuer un tri à partir d'une page arbitraire. Laisse-les (moi). Il n’ya rien de plus ennuyant que d’être là où vous voulez être, et qu’une application vous ramène au début de la liste.

Une autre considération concerne les multiples niveaux de tri: voulez-vous implémenter le tri par numéro de série, puis nom d'utilisateur? Considérez ce que fait Microsoft Excel ou toute autre application connue de vos utilisateurs. Vos utilisateurs seront probablement satisfaits de ce à quoi ils sont habitués - y compris le renvoi à la page 1.

Answer 2

Les bases de données sont de véritables bêtes lors du tri et de la sélection des données. Le mieux est donc certainement que le client dise au serveur: "Je veux la page X avec les rangées Y rangées par Z". Ensuite, la base de données fait son travail et le client affiche le résultat. Pour améliorer les performances, vous pouvez obtenir les résultats en cache de votre client. Vous pouvez également demander à votre code de demander les pages suivantes et précédentes après l'extraction de la page actuelle, afin qu'elles puissent être affichées instantanément sur demande.

Answer 3

La meilleure approche serait de faire le tri et la pagination au niveau de la base de données et de ne renvoyer qu’un sous-ensemble des données d’origine qui ne seront affichées qu’à l’écran. Pas de javascript dans ce scénario.

Si, pour certaines raisons, vous ne pouvez pas trier et feuilleter au niveau de la base de données, vous devez le faire avec un script côté serveur. Pas de javascript dans ce scénario non plus.

Et la pire approche serait de faire le tri et la pagination avec JavaScript, ce qui n’est bien sûr pas recommandé du tout pour des raisons évidentes.

Answer 4

Demandez à la base de données de trier ce qui est envoyé à la page à l'écran. Elle sera presque toujours plus rapide, sera mise en cache et facilitera le travail du navigateur.

Si vous le souhaitez, demandez au côté client d'autoriser le sous-tri supplémentaire via JavaScript, etc., si les données sont suffisamment détaillées et pourraient en tirer profit. Vous pouvez stocker les fonctionnalités de sous-tri. afin qu'ils soient mémorisés entre les pages.