| |
|
|
| | Как я понял, быстродействие интернет-магазина определяется, в основном, временем выполнения поискового запроса в базе. И это время, в большинстве случаев, весьма значительно.
А в моем случае имеет место такая ситуация.
База содержит сведения о категории товара, его наименовании, производителе и цене. Запрос из этой базы дает информацию на страницу с этим товаром (для каждого товара отдельная страница).
Но кроме этого, на странице с товаром выводится сообщение: «С этим товаром обычно покупают» и далее ссылки на три других товара из этой товарной группы. Эти ссылки тоже формируются запросами к базе. Причем запросов приходится делать не тори, а больше, поскольку выборка от каждого запроса не должна совпадать с товаром на этой странице и с другими выборками для этого товара. Реально получается в среднем 4.21. То есть, за счет опции «С этим товаром покупают» быстродействие магазина ухудшается в 4 раза.
Можно ли улучшить этот алгоритм для повышения быстродействия? | |
| |
|
|
| |
|
|
| |
для: Владимир55
(25.12.2010 в 10:25)
| | | «С этим товаром обычно покупают» и далее ссылки на три других товара из этой товарной группы
ну как правило товарная группа должна быть другой
если вы купили монитор, то врядли вы поверите, что кто-то с одинм монитором покупает второй в придачу. скорее всего это дожны быть салфетки, шнуры, и настенные крепления.
но как категория "аналогичные модели ценовой категории" как раз самое оно.
лечение "по фотографии" без самой "фотографии" тут не прокатит :)
нужна структура БД и сам запрос
ну а то что все это происходит в 4 раза медленнее конечно же не хорошо.
__
смею предположить, что теги у Вас в одном поле через запятую? | |
| |
|
|
| |
|
|
| |
для: Valick
(25.12.2010 в 11:36)
| | | У меня другая ситуация - мне нужны товары именно из моей товарной группы. Потому, что это книги. Если книги по строительству, то с ними и покупают книги по строительству (а не сказки или книги по биологии).
Это слегка упрощает дело в плане построения запроса на выборку, но не решает задачу повышения быстродействия. | |
| |
|
|
| |
|
|
| |
для: Владимир55
(25.12.2010 в 11:41)
| | | тогда да
показывайте запросы
я так понимаю искомая книга идет выборкой по id этой книги
а остальные случайные три из данной категории? | |
| |
|
|
| |
|
|
| |
для: Valick
(25.12.2010 в 11:49)
| | | Да, именно так.
Запрос прямо сейчас не напишу, поскольку прежде мне придется его найти... | |
| |
|
|
| |
|
|
| |
для: Владимир55
(25.12.2010 в 11:55)
| | | на самом деле мне кажется подход со случайной выборкой тут не уместен (хотя бы по этическим соображениям)
нужна именно отдельная таблица содержащая минимум два поля для сбора статистики покупок
кпримеру человек купил три книги с ай-ди 5, 9, 17
в итоге в таблицу записываем
5 | 9
5 | 17
9 | 5
9 | 17
17 | 5
17 | 9
|
теперь несложно пердставить себе запрос например для книги с ай-ди 9
с группировкой по id_add и вычислением процентного соотношения предлагаемой случайой (или по определенному критерию) выбранной книг(и) | |
| |
|
|
| |
|
|
| |
для: Valick
(25.12.2010 в 13:32)
| | | По этическим причинам не подходит, это верно. Но этика и бизнес несовместимы.
Магазину нужны продажи, но не только в этом дело. Главное - перелинковка как элемент поискового продвижения. Плюс активация поисковиков.
Случайный выбор решает эти проблемы.
Альтернативное решение - создание детерминированные таблицы перелинковки. Но это сложнее, ибо при удалении товара с продажи нужно искать все ссылки на него и удалять и их тоже. А при добавлении товара нужно искать, откуда на него сослаться. | |
| |
|
|
