Hier is een idee. U kunt de dure bewerkingen overdragen aan een update wanneer de kruidenier nieuwe aanbiedingen invoegt/bijwerkt in plaats van wanneer de eindgebruiker de gegevens selecteert om te bekijken. Dit lijkt misschien een niet-dynamische manier om de sorteergegevens te verwerken, maar het kan de snelheid verhogen. En, zoals we weten, is er altijd een afweging tussen prestaties en andere coderingsfactoren.
Maak een tabel voor volgende en vorige voor elke aanbieding en elke sorteeroptie. (U kunt dit ook in de aanbiedingstabel opslaan als u altijd drie sorteeropties heeft -- de querysnelheid is een goede reden om uw database te denormaliseren)
Dus je zou deze kolommen hebben:
- Sorteertype (ongesorteerd, prijs, klasse en prijsafschrijving)
- Aanbiedings-ID
- Vorige ID
- Volgende ID
Wanneer de detailinformatie voor de aanbiedingsdetailpagina wordt opgevraagd uit de database, zouden de NextID en PrevID deel uitmaken van de resultaten. U heeft dus maar één zoekopdracht nodig voor elke detailpagina.
Elke keer dat een aanbieding wordt ingevoegd, bijgewerkt of verwijderd, moet u een proces uitvoeren dat de integriteit/nauwkeurigheid van de sorttype-tabel valideert.