Постраничная навигация

[FiRеFоX]

Вот почитал эту тему:
http://habrahabr.ru/post/44608/
Ну вроде всё понятно.
А вот если такая ситуация:
Таблица: `perepiski` (id, id_login1, id_login2, data_msg) - data_msg - это обновляемое поле, показывает дату последнего письма в переписке
И вот нужно вывести на страницу мои переписки с другим пользователями сортируя по дате последнего письма в формате:
Логин_собеседника, дата последнего письма (по 10 логинов на страницу)
Допустим, что где-то на 15 строке в этой таблице сохранен юзер (его id строки в этой таблице - 15, а data_msg - time() (только что написал мне письмо))
Первая страница:

select * from `perepeski` order by `data_msg` desc limit 10;

Так как data_msg самая большая у нашего юзера на 15 строке, то он будет выведен на страницу.
Теперь я жму на вторую страницу:

select * from `perepeski` where `id` > 10 order by `data_msg` desc limit 10;

И опять наш юзер на 15 строке подходит под условие и будет выведен, но уже на второй странице.
Как быть?

 

[Volly]

where `id` > 10 - это несколько неудачно.
Попробуйте использовать второй параметр для limit
для первой страницы
select * from `perepeski` order by `data_msg` desc limit 0,10;
для второй страницы
select * from `perepeski` order by `data_msg` desc limit 9,10;
и т. д.

 

[brevis]

Вот почитал эту тему: http://habrahabr.ru/post/44608/
Как быть?

Оптимизировали-оптимизировали да не выоптимизировали.

Первая страница:

select * from `perepeski` order by `data_msg` desc limit 10;

Вторая страница:

select * from `perepeski` where `data_msg` < _даты_последней_записи_на_ПЕРВОЙ_странице_ order by `data_msg` desc limit 10;

Третья страница:

select * from `perepeski` where `data_msg` < _даты_последней_записи_на_ВТОРОЙ_странице_ order by `data_msg` desc limit 10;

...

N-ная страница:

select * from `perepeski` where `data_msg` < _даты_последней_записи_на_(N-1)_странице_ order by `data_msg` desc limit 10;

Только дату нужно хранить в микросекундах.

 

[FiRеFоX]

Бревис, и как скрипту узнать "_даты_последней_записи_на_ПЕРВОЙ_странице_", если чел перешел на страницу по ссылке или через форму "перейти к странице:"? Например на 500ю страницу он перешел, то как скрипт узнает какая дата была на 499?

 

[brevis]

Там же написано:

В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.

А как сделать 1..2..3..4 по методу аффтара у него и спроси.

 

[FiRеFоX]

 

[mrlasking]

Хабр славится не только постами, но и комментами к ним. http://habrahabr.ru/post/44608/#comment_1121731 ответ в рамках сабжа на вопрос Фокса.

У меня другой вопрос - на дворе давно не 2008 год, я каюсь, не гоняю тесты каждую неделю - но у меня запущено несколько десятков приложений для социалок, с разбросом от 3 до 100 тысяч просмотров в день, в которых я использовал пейджинг вида "1 2 3 4 .... 100500" используя limit и подсчет страниц. Для понимания - гоняют они таблички от полумиллиона до 5-6 миллионов записей. Проблем с производительностью нет. Есть ли смысл выкорячиваться из-за сабжа?

У автора в 2008 году 16000 строк читается за 0,13 сек. А, для сравнения, у меня в запросе "SELECT * FROM `card_activity_log` LIMIT 600000 , 10", который бежит по 600к строк, время выполнения = "Showing rows 0 - 9 ( 10 total, Query took 0.0429 sec)".

Стоит ли игра свеч?)

 

[FiRеFоX]

Хабр славится не только постами, но и комментами к ним. http://habrahabr.ru/...comment_1121731 ответ в рамках сабжа на вопрос Фокса.

У меня другой вопрос - на дворе давно не 2008 год, я каюсь, не гоняю тесты каждую неделю - но у меня запущено несколько десятков приложений для социалок, с разбросом от 3 до 100 тысяч просмотров в день, в которых я использовал пейджинг вида "1 2 3 4 .... 100500" используя limit и подсчет страниц. Для понимания - гоняют они таблички от полумиллиона до 5-6 миллионов записей. Проблем с производительностью нет. Есть ли смысл выкорячиваться из-за сабжа?

У автора в 2008 году 16000 строк читается за 0,13 сек. А, для сравнения, у меня в запросе "SELECT * FROM `card_activity_log` LIMIT 600000 , 10", который бежит по 600к строк, время выполнения = "Showing rows 0 - 9 ( 10 total, Query took 0.0429 sec)".

Стоит ли игра свеч?)

Дело не в игре, а в правильности Я хочу делать правильно, а не с мыслями "сойдет и так на первое время".. Если я буду делать сайты "как умею", то так ничему и не научусь новому

 

[mrlasking]

Ну вот я и задаю вопрос - а почему ты решил, что сейчас так писать правильнее?) Давайте все сдувать пыль с талмудов по ассемблеру и каждый бит памяти учитывать, тоже ведь правильнее)

Ты напиши сначала хорошее, красивое решение с limit - посмотри, покрути, пойми что и почему и как - и если сам дойдешь, до того, что нужно переделывать - дык вперед) Но ой не думаю я так. А считать "это правильно" - прочитав один пост, при том не факт что уже актуальный - вот это лично я считаю не оч правильным.

P.S. Кстати, Фокс я на тя обиделся) Я тебе пишу, что описываемый способ в рабочих проектах использую - показываю на примере пробега по 600 000 строкам, а ты это все резюмируешь фразой "на первое время сойдет". Нет у тя совести

 

[FiRеFоX]

Ну вот я и задаю вопрос - а почему ты решил, что сейчас так писать правильнее?) Давайте все сдувать пыль с талмудов по ассемблеру и каждый бит памяти учитывать, тоже ведь правильнее)

Потому что я сам посмотрел и всё проверил Я не принимаю всё на словах

P.S. Кстати, Фокс я на тя обиделся) Я тебе пишу, что описываемый способ в рабочих проектах использую - показываю на примере пробега по 600 000 строкам, а ты это все резюмируешь фразой "на первое время сойдет". Нет у тя совести

Нууу... Зря обижаешься У тебя то запрос простой и без сортировки. А у меня два join'а, а ещё большое where и сортировка по дате Поэтому последняя страница генерится примерно 1 сек

 

[mrlasking]

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

 

[FiRеFоX]

Оке, я б, конечно, посмотрел бы на этот запрос)

Пожалуйста:

SELECT
`chat`.`id` as `id_post`, `user`.`login`, `chat`.`id_login`, `chat`.`text`, `chat`.`privat`, `chat`.`id_login_komu`, `otvet`.`login` AS `login_komu`, `chat`.`data`
FROM `chat`
LEFT JOIN `user` ON `chat`.`id_login` = `user`.`id`
LEFT JOIN `user` AS `otvet` ON `chat`.`id_login_komu` = `otvet`.`id`
WHERE `chat`.`id_room` = 1 AND `chat`.`unset` != 1 AND (`chat`.`id_login` = '1' OR `chat`.`privat` = 0 OR `chat`.`id_login_komu` = '1') ORDER BY `chat`.`data` DESC LIMIT 0, 15

Поля: id_room - номер комнаты чата (от 1 до 5), unset - статус поста (1 - удалено, остальное - не удалено), privat - приватность поста (1 - приватно, остальное - в общий чат)
В первом соединении с таблицей юзеров мы узнаем данные автора поста.
Во втором соединении с таблицей юзеров мы узнаем данные пользователя, которому сообщение адресовано.
Условие в данном запросе обозначает, надо вытащить неудалённые посты(написанные мной или не приватные или адресованные мне) с комнаты 1. Ну и сортируются все сообщения по дате поста.

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

Какого именно кеширования? html, mysql, php? В php я кеширую в сессию некоторые результаты запросов, например "select count(*)", где это возможно. С кешированием mysql пока не подружился

 

[CamaroSS]

Можно кэшировать на уровне php-акселератора.
А Query Cache в MySQL очень специфичен.

 

[aegnor]

:blink: