Oto pomysł. Możesz przenieść kosztowne operacje na aktualizację, gdy sklep spożywczy wstawi/zaktualizuje nowe oferty, a nie wtedy, gdy użytkownik końcowy wybierze dane do wyświetlenia. Może się to wydawać niedynamicznym sposobem obsługi sortowanych danych, ale może zwiększyć szybkość. Jak wiemy, zawsze istnieje kompromis między wydajnością a innymi czynnikami kodowania.
Utwórz tabelę do przechowywania następnej i poprzedniej dla każdej oferty i każdej opcji sortowania. (Alternatywnie możesz zapisać to w tabeli ofert, jeśli zawsze będziesz mieć trzy opcje sortowania -- szybkość zapytań jest dobrym powodem do denormalizacji bazy danych)
Więc masz te kolumny:
- Typ sortowania (nieposortowane, cena, klasa i opis ceny)
- Identyfikator oferty
- Poprzedni identyfikator
- Następny identyfikator
Gdy informacje szczegółowe dotyczące strony szczegółów oferty są pobierane z bazy danych, identyfikatory NextID i PrevID będą częścią wyników. Potrzebujesz więc tylko jednego zapytania dla każdej strony szczegółów.
Za każdym razem, gdy oferta jest wstawiana, aktualizowana lub usuwana, musisz uruchomić proces, który weryfikuje integralność/dokładność tabeli sorttype.
