Ecco un'idea. È possibile scaricare le costose operazioni su un aggiornamento quando il droghiere inserisce/aggiorna nuove offerte anziché quando l'utente finale seleziona i dati da visualizzare. Questo può sembrare un modo non dinamico per gestire i dati di ordinamento, ma può aumentare la velocità. E, come sappiamo, c'è sempre un compromesso tra prestazioni e altri fattori di codifica.
Crea una tabella da tenere successiva e precedente per ogni offerta e ogni opzione di ordinamento. (In alternativa, puoi memorizzarlo nella tabella delle offerte se avrai sempre tre opzioni di ordinamento:la velocità delle query è una buona ragione per denormalizzare il tuo database)
Quindi avresti queste colonne:
- Tipo di ordinamento (non ordinato, prezzo, classe e descrizione prezzo)
- ID offerta
- ID precedente
- ID successivo
Quando le informazioni dettagliate per la pagina dei dettagli dell'offerta vengono richieste dal database, NextID e PrevID farebbero parte dei risultati. Quindi avresti bisogno solo di una query per ogni pagina dei dettagli.
Ogni volta che un'offerta viene inserita, aggiornata o eliminata, è necessario eseguire un processo che convalidi l'integrità/accuratezza della tabella sorttype.
