ссылки next и и previous без sql-запроса

[A1x]

я не вижу никаких вариантов кроме трех запросов

а сделать LIMIT 3 ?

 

[HEm]

Учтите, что и сортировка может быть различной
Например в списке стояла сортировка по цене, выбрали товар и хотим посмотреть следующий
А другой клиент поставил сортировку по названию и так же листает

Кстати, уже несколько раз такое требование исходило от клиентов, нравится им эта фишка.

по делу, да - лишний запрос по такой выборке меня не напрягает

 

[stopkran]

по делу, да - лишний запрос по такой выборке меня не напрягает

Дело не в mysql, я неточно выразил свои сомнения в начале темы. Плохо то, что приходится вычислять позиции каких-то товаров два раза: первый раз на странице списка, второй раз - при получении страницы элемента.

И да, один клиент ставит одну сортировку, другой - другую, - и каждый раз запрос в двух местах править, и весь код вокруг него в двух местах ворошить?

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

 

[HEm]

Ну вот тебе алгоритм - при пробежке по списку ты всегда помнишь предыдущий товар, делаешь список $previous_goods
возьмем например, что в списке товары выстроились сортировкой так 1,3,5,2,4
$previous_goods == (1=>0, 3=>1, 5=>3, 2=>5, 4=>2)
ну и слепить из него обратный $next_goods == (1=>3, 3=>5, 5=>2, 2=>4, 4=>0) несложно

 

[stopkran]

HEm, зачем "лепить"? Почему нельзя использовать обычные array_search & next?

 

[WMix]

если научить скрипт выводить записи на запрос типа ?before=[ID], ?after=[ID],
те на сервере писать where id<$_GET['before'] limit 1 или where id>$_GET['after'] limit 1
то все получится и без дополнительного запроса!

 

[HEm]

на самом деле там вырастет офигенный хвост а не одна переменная, тут же надо помнить параметры списка еще

 

[Beavis]

если научить скрипт выводить записи на запрос типа ?before=[ID], ?after=[ID],
те на сервере писать where id<$_GET['before'] limit 1 или where id>$_GET['after'] limit 1
то все получится и без дополнительного запроса!

этот вариант уже был предложен и отметён

 

[stopkran]

на самом деле там вырастет офигенный хвост а не одна переменная, тут же надо помнить параметры списка еще

Да, параметры получения списка придётся где-то хранить. Изначально все они (включая строку поиска) есть в УРЛ. Проще всего, видимо, хранить именно УРЛ начального списка - в куки или в сессии, а перед генерацией страницы элемента получать (с помощью сохранённого УРЛ) исходный список и находить в нём next-previous.

 

[Фанат]

мысль хранить там же в URL тебе в голову не приходила?

 

[A1x]

если есть ссылки next и и previous значит есть список отсортированный по некоторому правилу,
идентификатором произвольного элемента в этом списке можно сделать его offset (не первичный ключ!)

тогда этот элемент можно выбрать запросом типа SELECT ... WHERE ... ORDER BY <правило сортировки> OFFSET N LIMIT 2

LIMIT 2 делаем для того чтобы узнать а есть ли там next, если есть то его OFFSET будет N + 1 previous будет соответственно N - 1

зачем еще один запрос?