так будет быстрее:
[PHP]$current_page = (int) $_GET['page'];[/PHP]


Да и лучше mysqli или pdo заюзать

я сторонюсь универсальных скриптов. На вырост, скажем так. Инт не пропустит большие цифры. Из 10 чисел, например.

Кому лучше? Придираетесь. У меня например другой фреймворк, но с нативными функциями-то лучше разбираться.
По коду.
пагинация д.б. функцией, и БД там вообще ни при чем.

Вот из движка функция:
[PHP]
function rcms_pagination($total, $perpage, $current, $link){
$return = '';
$link = preg_replace("/((&|&)page=(\d*))/", '', $link);
if(!empty($perpage)) {
$pages = ceil($total/$perpage);
if($pages != 1){
$c = 1;
while($c <= $pages){
if($c != $current) $return .= ' [' . '<a href="' . $link . '&amp;page=' . $c . '">' . $c . '</a>] ';
else $return .= ' [' . $c . '] ';
$c++;
}
}
}
return $return;
}
[/PHP]
Выводит просто [1][2][3]
Текущая не ссылкой, остальные ссылками.
На входе: всего, сколько на странице, текущая страница и код ссылки.
Потом уже прикручивается к каждому из модулей где надо пагинация:
[PHP] $cur=$from-1;
$tcount=fn_get_article_count_category($category_id);
$query='SELECT * from `articles` WHERE `category`="'.$category_id.'" ORDER BY `date` DESC LIMIT '.($cur)*$perpage.','.$perpage.'';
$allarticles=simple_queryall($query);
if (!empty ($allarticles)) {
$link='?module=fn&c='.$container.'&b='.$category_id.'';
$result.=rcms_pagination($tcount,$perpage, $from, $link).'<br />';
}
[/PHP]
Мало где понадобится? В статьях, форуме, галерее...

Ни в коем случае =)
Возможно, в следующих версиях php эти функции не будут поддерживаться.

1. СЕЛЕКТ
2. SQL_CALC_FOUND_ROWS
3. ФРОМ
4. блаблабла(вские ДЖОЙН и т.п.)
5. ГРУП БАЙ <ФРОМ>.первичный ключ
6. ЛИМИТ <с какой записи>,<сколько записей>
7. ;
8. СЕЛЕКТ
9. FOUND_ROWS()
10. ;

Почему столь подробно объясняю и на русском - потому что автор судя по этому коду
[PHP]
$query_num = "SELECT id FROM table_name";
$res_num = mysql_query($query_num) or die(mysql_error());
// всего записей
$num = mysql_num_rows($res_num);
[/PHP]
Даже не подозревает об агреггирующей функции COUNT(), уже не говоря о том что при выборке всей таблице для MyISAM вообще достаточно будет получить 1 давно готовое значение из свойств таблицы. А значит производительность будет в 1000 раз выше.
В общем печалька :zloy:

Arks, сказал вроде бы умную и полезную вещь, под неё бы ещё пример понятный (ну чтобы не гуглить лишний раз).

я не говорил, что это идеальный код. Мерять достоинство тоже тут смысла нет. Тыкать меня в то, чего я, например, не знаю - смысла нет. Я не на олимпиаду код пишу. Выигрывать наносекунды смысла нет. Везде прошли 90е и динозавры канули. Если этот код будет выполняться на пол секунды дольше, то это тоже не страшно. Страшно строить диалог не как "смотри как еще можно - давай покажу/научу", а как "ты ничего не умеешь и ничего не знаешь. И вообще - в поиск".

Galen,
Licoric,
Это все конечно замечательно, но пример чтобы сделать мне надо потратить часа полтора своего времени, сделать тестовую БД из пары миллионов разных строк, оформить все это в виде структуры БД и представить код с точки зрения разницы в производительности разных решений.
Я пишу так вовсе не потому что это "в поиск", а потому что писать это специально реально долго, а в поиске это уже освещено. Я лишь представил концепцию. и указал на явные ошибки.


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

P.S.
Тут то как раз смысл есть, даже если Вы не оценили. Было бы странно тыкать в то, что Вы знаете - кретинизмом вероятно.

Какие еще тут джойны? 2 запроса - один с количеством строк, второй - выхлоп математики. Не надо городить велосипед там, где мне надо выводить статическую страницу.

Повторюсь, может быть, излишними цитатами, но...



[...]

Не тыкал?)))