vovich Feb 23 2011 at 18:22

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

3 min

20K

Comments 39

NYMEZIDE Feb 23 2011 at 18:48

.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 Feb 23 2011 at 18:52

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

shai_hulud Feb 23 2011 at 18:58

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

vovich Feb 23 2011 at 19:00

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

shai_hulud Feb 23 2011 at 19:04

да не вы

Evgin Feb 23 2011 at 21:35

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

eternals Feb 24 2011 at 08:02

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

Angelina_Joulie Feb 24 2011 at 10:12

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

eternals Feb 24 2011 at 10:51

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

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

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

Angelina_Joulie Feb 24 2011 at 10:15

Правильно нужно использовать функции ранжирования (умею пользоваться только 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 Feb 23 2011 at 19:06

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

Pozadi Feb 23 2011 at 19:08

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

vovich Feb 23 2011 at 19:14

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

Pozadi Feb 23 2011 at 19:17

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

zerkms Feb 24 2011 at 02:44

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

zerkms Feb 24 2011 at 00:16

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

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

vovich Feb 24 2011 at 07:06

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

zerkms Feb 24 2011 at 07:14

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

Angelina_Joulie Feb 24 2011 at 10:18

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

vovich Feb 24 2011 at 10:35

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

vorbiz Feb 23 2011 at 20:14

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

aleks_raiden Feb 24 2011 at 06:40

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

vorbiz Feb 24 2011 at 08:13

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

zayko Feb 23 2011 at 20:40

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

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

Rakoth Feb 23 2011 at 20:47

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

vovich Feb 24 2011 at 07:12

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

zerkms Feb 24 2011 at 00:22

Решение в топике совершенно не уважает субд, потому как на каждый из 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 Feb 24 2011 at 04:57

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

zerkms Feb 24 2011 at 05:08

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

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

vovich Feb 24 2011 at 07:08

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

zerkms Feb 24 2011 at 07:10

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

vovich Feb 24 2011 at 07:23

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

zerkms Feb 24 2011 at 07:38

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

vovich Feb 24 2011 at 08:09

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

Angelina_Joulie Feb 24 2011 at 10:21

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

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

zerkms Feb 24 2011 at 10:34

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

vovich Feb 24 2011 at 07:30

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

zerkms Feb 24 2011 at 07:38

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

ctapnep Mar 9 2011 at 22:32

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