Her er en idé. Du kan overføre de dyre operationer til en opdatering, når købmanden indsætter/opdaterer nye tilbud, i stedet for når slutbrugeren vælger de data, der skal ses. Dette kan virke som en ikke-dynamisk måde at håndtere sorteringsdata på, men det kan øge hastigheden. Og som vi ved, er der altid en afvejning mellem ydeevne og andre kodningsfaktorer.
Opret en tabel til næste og forrige for hvert tilbud og hver sorteringsmulighed. (Alternativt kan du gemme dette i tilbudstabellen, hvis du altid vil have tre sorteringsmuligheder -- forespørgselshastighed er en god grund til at denormalisere din database)
Så du ville have disse kolonner:
- Sorteringstype (usorteret, pris, klasse og prisbeskrivelse)
- Tilbuds-id
- Forrige ID
- Næste ID
Når detaljeoplysningerne for tilbudsdetaljesiden søges fra databasen, vil NextID og PrevID være en del af resultaterne. Så du behøver kun én forespørgsel for hver detaljeside.
Hver gang et tilbud indsættes, opdateres eller slettes, skal du køre en proces, der validerer sorttypetabellens integritet/nøjagtighed.