Voici une idée. Vous pouvez décharger les opérations coûteuses sur une mise à jour lorsque l'épicier insère/met à jour de nouvelles offres plutôt que lorsque l'utilisateur final sélectionne les données à afficher. Cela peut sembler être une manière non dynamique de gérer les données de tri, mais cela peut augmenter la vitesse. Et, comme nous le savons, il y a toujours un compromis entre les performances et d'autres facteurs de codage.
Créez un tableau contenant le suivant et le précédent pour chaque offre et chaque option de tri. (Alternativement, vous pouvez stocker cela dans la table des offres si vous avez toujours trois options de tri - la vitesse de requête est une bonne raison de dénormaliser votre base de données)
Vous auriez donc ces colonnes :
- Type de tri (non trié, prix, classe et description du prix)
- Identifiant de l'offre
- Identifiant précédent
- Identifiant suivant
Lorsque les informations détaillées de la page de détail de l'offre sont interrogées à partir de la base de données, NextID et PrevID font partie des résultats. Vous n'auriez donc besoin que d'une seule requête pour chaque page de détail.
Chaque fois qu'une offre est insérée, mise à jour ou supprimée, vous devez exécuter un processus qui valide l'intégrité/précision de la table sorttype.
