Hier ist eine Idee. Sie könnten die teuren Vorgänge auf eine Aktualisierung auslagern, wenn der Lebensmittelhändler neue Angebote einfügt/aktualisiert, anstatt wenn der Endbenutzer die anzuzeigenden Daten auswählt. Dies mag wie eine nicht dynamische Art und Weise erscheinen, die Sortierdaten zu handhaben, aber es kann die Geschwindigkeit erhöhen. Und wie wir wissen, gibt es immer einen Kompromiss zwischen Leistung und anderen Codierungsfaktoren.
Erstellen Sie für jedes Angebot und jede Sortieroption eine Tabelle, die das nächste und das vorherige enthält. (Alternativ könnten Sie dies in der Angebotstabelle speichern, wenn Sie immer drei Sortieroptionen haben – die Abfragegeschwindigkeit ist ein guter Grund, Ihre Datenbank zu denormalisieren)
Sie hätten also diese Spalten:
- Sortiertyp (Unsortiert, Preis, Klasse und Preisbeschreibung)
- Angebots-ID
- Vorherige ID
- Nächste ID
Wenn die Detailinformationen für die Angebotsdetailseite aus der Datenbank abgefragt werden, wären die NextID und PrevID Teil der Ergebnisse. Sie würden also nur eine Abfrage für jede Detailseite benötigen.
Jedes Mal, wenn ein Angebot eingefügt, aktualisiert oder gelöscht wird, müssten Sie einen Prozess ausführen, der die Integrität/Genauigkeit der Sorttype-Tabelle validiert.
