Vaut-il mieux intégrer un jeu de données complet s'il y a beaucoup de filtrage ajax sur la page?

Question

J'ai essentiellement cette page Web où vous pouvez affiner vos résultats de recherche en ajoutant et en supprimant certains filtres sur le côté gauche.

Le contenu tiré de la base de données est une liste de propriétés, qui peut être filtré par:

• Type (Camp, Ranch, Camp de pêche, Hôtel, Lodge)
• Activités (Camping , kayak, chasse)
• Lieu (Idaho, Illinois, Indiana)

donc chaque fois que je clique sur l'un des filtres valides sur le côté gauche, il ajoute que les critères de filtrage qui est utilisé dans une requête ajax. Cela rejoint le nombre minimum de tables nécessaires et renvoie les résultats. Donc, si je joue et que j'active/je désactive, je peux facilement faire environ 20 à 30 requêtes ajax en environ une minute (vous êtes seulement autorisé à filtrer un de chaque type à la fois, sauf si vous le désactivez) .

Question: Je me demande si je devrais avoir la place tous tiré les propriétés et les possibles simplement filtré au lieu d'interroger la base de données pour chaque demande ajax, qui a au moins 2-3 LEFT JOIN s par transaction.

Il va y avoir moins de 100 propriétés, je ne parle pas de centaines ou de milliers.

Answer 1

Absolument: Tirez l'ensemble de données complet et filtrez dessus. Disons que chacune de vos requêtes Ajax prend 100ms. Déjà, vous pourriez parler d'introduire 2-3 secondes de latence dans votre application lorsque, avec votre petit jeu de données, vous n'en avez pas vraiment besoin.

Si vous réduisez une liste de résultats, "object oriented CSS" peut être votre ami ici aussi. Pensez à exprimer les différentes propriétés filtrables en tant que classes et en ajoutant les filtres sélectionnés par l'utilisateur à leur parent, puis en utilisant CSS pour afficher ou masquer les résultats pertinents.

Par exemple, si vous avez tous vos résultats comme LI s sous un parent UL, <ul class="idaho apartment"> pourrait indiquer l'utilisateur filtré sur tous les articles de l'appartement Idaho alors que le CSS suivant cacherait les autres:

.apartment .camp, .apartment ranch ... { display : none; } 
.idaho .illinois, .idaho indiana{ display: none; } 

Avec cette approche, vous avez un seul serveur touché et compte sur le navigateur + JavaScript pour gérer le reste (et puisque vous utilisez des comparaisons booléennes - un résultat a une propriété ou non - cela pourrait bien fonctionner pour vous). Quoi qu'il en soit, même sélectionner des nœuds manuellement lorsque vous filtrez sera plus rapide que d'envoyer une requête par filtre. De plus, vous auriez maintenant la possibilité de mettre en cache cette requête de base de données unique, ce qui pourrait vous faire économiser beaucoup de temps supplémentaire si vous avez besoin d'exécuter des requêtes complexes.

Servez l'ensemble complet!

Answer 2

Pouvez-vous réécrire votre requête ajax afin que, au lieu de retourner une liste de propriétés, il retourne simplement leurs identifiants? Est-ce que cela réduit le nombre de LEFT JOIN s?

Ensuite, vous pouvez parcourir ces identifiants, en appelant une autre requête ajax pour obtenir les propriétés que vous n'avez pas déjà mises en cache depuis le filtrage précédent.