Выбираем предыдущую и следующую запись зная id

[NYMEZIDE]

.Net LINQ

Prev
(from t in Table
where t.ID < ActiveID && (… условия фильтрации...)
select t)
.Skip(1).Take(1)

Next
(from t in Table
where t.ID > ActiveID && (… условия фильтрации...)
select t)
.Take(1)

, где ActiveID = текущему ID

[vovich]

а Вы уверены что у предыдущей записи ID будет меньше текущей?

[shai_hulud]

вот из-за таких как ты наш язык называют быдлокодерским

[vovich]

мм в смысле? что Вам не понравилось?

[shai_hulud]

да не вы

[Evgin]

А как надо правильно?

[eternals]

Правильно надо использовать курсоры.
Но программистам mysql этого не понять.

[Angelina_Joulie]

Это какая-то шутка.

[eternals]

Это не шутка, это троллинг. Здесь не с кем шутить.

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

Чем Вам курсоры не понравились? Они, кстати, лучше ранжирования, т.к. при ранжировании (насколько я знаю) при повторных запросах перестроение результата может произойти.

[Angelina_Joulie]

Правильно нужно использовать функции ранжирования (умею пользоваться только MS SQL Server'ом)

SELECT i.ProductID, p.Name, i.LocationID, i.Quantity
,RANK() OVER
(PARTITION BY i.LocationID ORDER BY i.Quantity DESC) AS 'RANK'
FROM Production.ProductInventory i
INNER JOIN Production.Product p
ON i.ProductID = p.ProductID
ORDER BY p.Name;

Вот посте такого, предыдущий будет меньше на единицу.
И уже если речь зашла о Linq2Sql & Linq2Entities, то использование Skip() & Take() не избежно приводит к использованию функций ранжирования и по этому применяются только с оператором OrderBy/OrderByDescending

Как-то так)

[Pozadi]

Не пойму что вы пытаетесь оптимизировать.

[Pozadi]

Не дописал, случайно отправилось…
У вас сейчас составлен запрос так что он возвращает порядковый номер по id, может проще получить просто отсортированные id, и на стороне php посчитать порядковый номер.

[vovich]

эмм ну у меня просто какбы 10 000 записей уже, ну и как бы у меня правило — все что можно вынести на СУБД — выносить. Я как-то фиксил код, «программист» педжинг делал средствами PHP, через месяц работы сайт начал падать на пейджинге.

[Pozadi]

Ясно, тогда наверное есть смысл.

[zerkms]

Смысла мало — потому что код в статье не многим лучше того, который «падал на пейджинге». Подробности ниже

[zerkms]

Вот именно — у вас 10к записей и вы предлагаете решение, которое всегда будет выполнять фуллскан по таблице с данными.

Добавьте, пожалуйста, EXPLAIN'ы к запросам

[vovich]

Вы можете предложить другое решение?

[zerkms]

Для двух условий сортировки с наскоку — не могу.

[Angelina_Joulie]

Может быть просто во временную таблицу всё положите и чёткой нумерацией.

[vovich]

да не волнуйтесь нету там фулскана всей таблицы — там условия where ограничивают. С временными таблицами — это под каждый where и order by делать? у меня все динамическое

[vorbiz]

Лять, мои глаза. Когда же все начнут пользоваться ORM? Хрен с ним, с пхп уже. Но доктрину можно было бы заюзать, так ведь?

[aleks_raiden]

зачем она везде?

[vorbiz]

За тем же, зачем stdlib везде в си.

[zayko]

За творческий порыв и усердие +1.

> Для простоты и лакончиности покажу решение используя PHP.
[irony]Да! Очень просто и лаконично![/irony]

[Rakoth]

Если при переходе с index на view передать дополнительным параметром порядковый номер записи в текущем отображении на странице, посчитанный с помощью js или указанный при генерации страницы (с учетом пагинации) то не придется вообще искать этот номер и можно будет использовать «LIMIT row_number, 1» для поиска текущей записи. А для ссылок сделать ±1 к этому параметру.
Да, выборка текущего элемента будет осуществляться не по первичному ключу, однако исчезает необходимость искать id соседних записей.

[vovich]

дык этож шило на мыло менять, у меня один раз по recno берется и у Вас тоже самое. Да и еще на indexe завязываться на recno

[zerkms]

Решение в топике совершенно не уважает субд, потому как на каждый из 2х запросов статьи будет выполняться фуллскан.

Выбираем искомую запись
select *
from tbl
where name = 'test' and id = $pk
ORDER BY name, surname
limit 1

Выбираем PK записи

Следующая:

select *
from tbl
where name = 'test' and id = $pk
ORDER BY name, surname
limit 1, 1

Предыдущая

select *
from tbl
where name = 'test' and id = $pk
ORDER BY name DESC, surname DESC
limit 1, 1

Вот эти запросы смогут использовать индексы. Как следствие — будут выполняться быстро.

[Rakoth]

Последние запросы вернут пустой ответ, так как условие id = $pk противоречит условию limit 1, 1. Если только в таблице нет нескольких записей с одним id. Или я чего-то не понимаю?

[zerkms]

Ага, я поторопился. Ещё когда писал запросы подсознание мне говорило, что не всё так просто :-)

Тогда отбой, мой вариант не считается (однако это всё равно не даёт права на существование варианту из топика).

[vovich]

там еще такое дело, что в моем случае like есть всегда, а это значит капец индксам.

[zerkms]

Вы написали решение, в замен тому, которое ломалось на 10к. Но ваше тоже «сломается», когда данных станет хотя бы 10М

[vovich]

нуу 10М данных там не будет, на такое кол-во данных надо уже не MYSQL брать. MYSQL вообще с индексами работает хреново.

[zerkms]

mysql отлично работает с индексами и 10М в нормальной базе вообще объём смешной

[vovich]

нуу эта тема уже для другого топика. Но мое мнение на больших объемах данных лучше использовать PostgreSQL. Не то что MYSQL не справится, но как-то PostgreSQL с индексами получше. Но давайте в рамках данного топика не будем спорить об этом.
вот тут www.fight.org.ua/database/mysql_vs_pgsql.html можно почитать

[Angelina_Joulie]

Да? Не уверена что утверждение корретно.

10млн integer'ов — да, фигня. Всего-то 4*10млн — 40Мб для дисковых массивов — пшик.
А вот 10 млн, скажем nvarchar'ов, эдак под 1024 байта — это уже серъёзно базу заставит задуматься.

[zerkms]

Не заставит. Выберите префиксом, к примеру, пару десятков байт. Этого более чем достаточно, чтобы из такого небольшого числа искать (при условии, что у вас там разные строки, а не одно и то же, естественно).

[vovich]

И еще там в 90% случаев будет фулска не всей таблицы — так как стоит условие where, я проверял. Так что не все так страшно.

[zerkms]

Угу, пардон, будет скан по выбранным записям (чтобы их вручную пронумеровать)

[ctapnep]

Если ставить задачу как «найти следующую запись имея только текущую», то да, приходится извращаться подобным образом. Но обычно такой задачи не стоит. Почему? Да потому, что нет никакой проблемы в PHP (или что там обращается к базе) держать одну переменную с оффсетом записи. И потом спокойно выбирать следующuю обычным select...limit N+1,1.