Оптимизация запросов для следующего и предыдущего элемента

Вот идея. Вы можете перенести дорогостоящие операции на обновление, когда продуктовый магазин вставляет / обновляет новые предложения, а не когда конечный пользователь выбирает данные для просмотра. Это может показаться нединамическим способом обработки данных сортировки, но это может увеличить скорость. И, как мы знаем, всегда есть компромисс между производительностью и другими факторами кодирования.

Создайте таблицу для хранения следующего и предыдущего для каждого предложения и каждого варианта сортировки. (В качестве альтернативы вы могли бы сохранить это в таблице предложений, если у вас всегда будет три варианта сортировки - скорость запроса является хорошим поводом для денормализации вашей базы данных)

Таким образом, у вас будут следующие столбцы:

• Тип сортировки (Несортировано, Цена, Класс и Цена)
• Идентификатор предложения
• Предыдущий идентификатор
• Следующий идентификатор

Когда подробная информация для страницы сведений о предложении запрашивается из базы данных, NextID и PrevID будут частью результатов. Таким образом, вам потребуется только один запрос для каждой страницы сведений.

Каждый раз, когда предложение вставляется, обновляется или удаляется, вам нужно будет запустить процесс, который проверяет целостность / точность таблицы сортировки.

Я не уверен, правильно ли я понял, так что если нет, просто скажите мне;)

Допустим, что данные являются запросом для отсортированного списка и текущего смещения в этом списке, т.е. у нас есть $query и $n.

Очень очевидным решением для минимизации запросов является выборка всех данных одновременно:

list($prev, $current, $next) = DB::q($query . ' LIMIT ?i, 3', $n - 1)->fetchAll(PDO::FETCH_NUM);

Этот оператор извлекает предыдущий, текущий и следующий элементы из базы данных в текущей сортировке. порядок и помещает связанную информацию в соответствующие переменные.

Но так как это решение слишком простое, я полагаю, что я что-то неправильно понял.

Основные предположения:

• Специальные предложения еженедельно
• Мы можем ожидать, что сайт будет меняться нечасто ... вероятно, ежедневно?
• Мы можем контролировать обновления для базы данных с эфиром API или ответа через триггеры

Если сайт меняется ежедневно, я предлагаю, чтобы все страницы генерировались статически за ночь. Один запрос для каждого порядка сортировки перебирает и создает все связанные страницы. Даже если есть динамические элементы, есть вероятность, что вы можете обратиться к ним, включив статические элементы страницы. Это обеспечит оптимальный сервис страниц и не будет загружать базу данных. Фактически, вы можете создать отдельные страницы и элементы prev / next, которые будут включены в страницы. Это может быть сумасшедшим с 200 способами сортировки, но с 3 я большой поклонник этого.

?sort=price
include(/sorts/$sort/tomatoes_class_1)
/*tomatoes_class_1 is probably a numeric id; sanitize your sort key... use numerics?*/

Если по какой-то причине это невозможно, я бы прибегнул к запоминанию. Memcache популярен для такого рода вещей (каламбур!). Когда что-то передается в базу данных, вы можете запустить триггер, чтобы обновить кеш с правильными значениями. Сделайте это так же, как если бы ваш обновленный элемент существовал в трех связанных списках - при необходимости измените связь (this.next.prev = this.prev и т. Д.). Исходя из этого, до тех пор, пока ваш кэш не переполняется, вы будете извлекать простые значения из памяти способом первичного ключа.

Этот метод потребует некоторого дополнительного кодирования в методах выбора и обновления / вставки, но он должен быть довольно минимальным. В конце концов, вы будете искать [id of tomatoes class 1].price.next. Если этот ключ находится в вашем кеше, золотой. Если нет, вставьте в кеш и отобразите.

• Как вы думаете, это хорошая практика, чтобы найти соседние записи для различных порядков запросов? Да. Целесообразно выполнять прогнозирование ожидаемых предстоящих запросов.
• Знаете ли вы лучшие практики с точки зрения производительности и простоты? Знаете ли вы что-то, что делает это полностью устаревшим? Надеюсь, что выше
• В теории программирования, есть ли название для этой проблемы? Оптимизация?
• Является ли название «Кэш сортировки» подходящим и понятным для этой техники? Я не уверен в конкретном подходящем имени. Это кеширование, это своего рода кеш, но я не уверен, что если вы скажете, что у вас есть «кеш сортировки», вы получите мгновенное понимание.
• Существуют ли общепризнанные, общие модели для решения этой проблемы? Как они называются? Кеширование?

Извините, но мои ответы на вопросы не имеют смысла, но я думаю, что мои повествовательные решения должны быть весьма полезными.

Таким образом, у вас есть две задачи:

1. построить отсортированный список элементов (SELECT с разными ORDER BY)
2. показать подробности о каждом элементе (SELECT из базы данных с возможным кэшированием) .

В чем проблема?

PS: если упорядоченный список может быть слишком большим, вам просто нужно реализовать функциональность PAGER. Могут быть разные реализации, например Вы можете добавить «LIMIT 5» в запрос и предоставить кнопку «Показать следующие 5». Когда эта кнопка нажата, добавляется условие типа «ГДЕ цена < 0.89 LIMIT 5».