J'utilise un plug-in jquery appelé TableSorter Pour faire le tri du client d'une table en rondins dans l'une de mes applications. Je fais également usage de l'addition de table de table.
J'aime vraiment la réactivité que le tri et la pagination côté client apporte à la fête. J'aime aussi comment vous n'avez pas besoin de frapper le serveur Web ou la base de données à plusieurs reprises.
Cependant, je peux voir que, dans le temps, le journal que j'affiche pourrait devenir assez grand. Je suis sûr qu'il y a un point où la pagination et le tri côté client vont être irréalistes. De quel point cette technique commencera-t-elle à s'effondrer sous son propre poids? 500 enregistrements? 2000 enregistrements? 10 000 enregistrements?
EDIT: En nidshell, quels critères utiliseriez-vous pour déterminer si vous allez utiliser le tri / la pagination côté client par opposition à la pagination côté serveur? La taille du résultat attendu est-elle un facteur de définition de votre décision? Où est le point de basculement?
3 Réponses :
Cette technique s'effondrera probablement lorsque le navigateur ou l'hôte client ne peut pas le prendre.
Utilisez la pagination côté serveur pour éviter cela.
J'envisagerai d'abord la quantité de données que j'envoie au client, ce qui provoque à son tour le facteur de temps de chargement.
Dites si chaque rangée de la table est de 200 octets et j'envoie 10000 lignes au client (qui permet le tri et la pagination du client), j'envoie 200 * 10000 = 2 000 000 octets, alias 2 Mo. Cela prendra le navigateur un peu de temps pour le charger du serveur, puis un certain temps pour le plugin de tri pour trier tout, puis la pagination un peu de temps à la page.
En fait, votre charge de serveur augmentera avec la nécessité d'envoyer toutes les lignes au client.
Normalement avec tant de données et d'itérations pour JavaScript pour gérer, le navigateur (Firefox ou similaire) se bloquera et ressemblera comme s'il s'écrase.
Si vous utilisez le tri de serveur + pagination, le client voit les informations précises et à jour. Disons également que vous avez les mêmes 10000 lignes, chaque 200 octets. Vous avez 20 lignes par page. Vous n'envoyez que 20 * 200 = 4000 octets, qui est 4 kb, relativement petit et peut être géré par le navigateur / serveur.
Je cherchais une réponse qui m'a donné un peu plus de conseils. Je vais modifier ma question pour clarifier cela.
Quelques cents sont probablement corrects, en fonction du nombre de colonnes. Cela décomposera certainement lorsque vous traitez des données sur l'ordre de 10 ^ 3 (milliers).
Celles-ci ont été mes conclusions empiriques sur différents navigateurs, mais j'étais habituellement sur du matériel costaud. Je limiterais vos données définies à des centaines.
Cependant, je peux voir que, dans le temps, le Connectez-vous que j'affiche pourrait grandir grande. Je suis sûr qu'il y a un point où la pagination côté client et le tri va être irréalisable. Quel point cette technique commencera-t-elle à s'effondrer Sous son propre poids? 500 enregistrements? 2000 enregistrements? 10 000 enregistrements?
Cela dépend vraiment de nombreuses choses différentes comme le nombre de colonnes de taille de table et quel navigateur et la version utilisent la personne. Je peux systématiquement régler jusqu'à 1000 enregistrements avant de voir un vrai problème. Si vous commencez à approcher ce numéro, je commencerais certainement à regarder le tri du serveur. Avec Ajax, le tri latéral du serveur peut être assez efficace et avoir une expérience utilisateur décente.
Le meilleur moyen est de regarder votre situation particulière est de l'essayer et de voir. Les navigateurs mais pas vraiment conçus pour gérer de très grandes quantités de données telles que cela peuvent toujours le gérer. L'expérience utilisateur sera abyssale, mais le nombre d'enregistrements qu'il peut gérer est assez élevé.
En effet, il est (presque) totalement dépendant de la taille de la mémoire du client et de la vitesse du matériel (et même une vitesse du moteur JavaScript du navigateur).
En dehors de cela, en fonction de la taille des enregistrements, vous devez transférer beaucoup de données au client, chaque fois que la table est demandée; Cela pourrait coûter beaucoup de bande passante et, en fonction de la vitesse de la connexion, du temps.