Ето една идея. Можете да прехвърлите скъпите операции към актуализация, когато бакалинът вмъква/актуализира нови оферти, а не когато крайният потребител избере данните за преглед. Това може да изглежда като нединамичен начин за обработка на данните за сортиране, но може да увеличи скоростта. И както знаем, винаги има компромис между производителност и други кодиращи фактори.
Създайте таблица, която да държите следващата и предишната за всяка оферта и всяка опция за сортиране. (Алтернативно можете да съхраните това в таблицата с оферти, ако винаги ще имате три опции за сортиране - скоростта на заявката е добра причина да денормализирате вашата база данни)
Така че ще имате следните колони:
- Тип сортиране (несортирано, цена, клас и описание на цената)
- Идент. № на офертата
- Предишен идентификатор
- Следващ идентификатор
Когато подробната информация за страницата с подробности за офертата бъде запитана от базата данни, NextID и PrevID ще бъдат част от резултатите. Така че ще ви трябва само една заявка за всяка страница с подробности.
Всеки път, когато оферта се вмъкне, актуализира или изтрие, ще трябва да стартирате процес, който потвърждава целостта/точността на таблицата за сортиране.
