Поддерживаю. Хорошее решение. Вопрос "А зачем?" на эту тему давно себе не задаю, после трех месяцев, потраченных на перевод кода проекта с MS SQL на PostgreSQL. Там SQL и код приложения были в одной куче и это был реально трэш ))
Нет, не догадаюсь и догадываться не хочу, уж простите. Если вы не хотите быть понятым, с чего вдруг мне прикладывать к этому усилия ))) И кстати, никакого псевдокода в вашем примере нет. Это скорее недоразумение, а не пример ))
Копья ломаются по поводу того, что пагинация по limit/offset - плохо или вообще - пагинация зло. Но, по предложенному способу вроде замечаний особо нет )). Дело в том, что есть случаи, когда и объем и нагрузка небольшие и заказчик хочет вот простейшую пагинацию. Это мой случай как раз. ИМХО, с ума сходить не стоит и лучше сделать простейшим способом. Ну а когда/если понадобится оптимизация - тогда и будем морщить лоб )). Спасибо, коллеги!
А как же условия WHERE, в котором может быть много разных полей? Например, отображение товара в интернет магазине с фильтрацией по куче разных параметров (полей)? Как СУБД осуществит фильтрацию, читая только таблицу первичного индекса? Ничего не понимаю...
Поддерживаю. Хорошее решение. Вопрос "А зачем?" на эту тему давно себе не задаю, после трех месяцев, потраченных на перевод кода проекта с MS SQL на PostgreSQL. Там SQL и код приложения были в одной куче и это был реально трэш ))
"спустя четно потраченные нервы" - это звучит! )))) Вы сделали мой вечер!
Илья, спасибо! Прям ровно то, что я искал! С меня причитается! ))
Нет, не догадаюсь и догадываться не хочу, уж простите. Если вы не хотите быть понятым, с чего вдруг мне прикладывать к этому усилия ))) И кстати, никакого псевдокода в вашем примере нет. Это скорее недоразумение, а не пример ))
как можно сравнивать с чем-то id, когда это UUID?
Это не скелет, увы. Это просто непонятная строчка ))
" id > lastpage" - очаровательно :). Особенно учитывая то, что это разные типы данных в моём случае
Ни одного противоречия нет. Вы придираетесь )
Под морщить лоб я понимаю либо отказ от пагинации либо оптимизация для снижения нагрузки )
Копья ломаются по поводу того, что пагинация по limit/offset - плохо или вообще - пагинация зло. Но, по предложенному способу вроде замечаний особо нет )). Дело в том, что есть случаи, когда и объем и нагрузка небольшие и заказчик хочет вот простейшую пагинацию. Это мой случай как раз. ИМХО, с ума сходить не стоит и лучше сделать простейшим способом. Ну а когда/если понадобится оптимизация - тогда и будем морщить лоб )). Спасибо, коллеги!
А как же условия WHERE, в котором может быть много разных полей? Например, отображение товара в интернет магазине с фильтрацией по куче разных параметров (полей)? Как СУБД осуществит фильтрацию, читая только таблицу первичного индекса? Ничего не понимаю...
Не очень понял, почему
SELECT id FROM mega_tableбудет существенно быстрее, чемSELECT * FROM mega_tablСкиньте, плз, ссылку - что почитать про передовую мысль и last_id. Буду благодарен!
Вопрос не в том - делать или не делать пагинацию. Его решили без меня. Вопрос в данном случае - как сделать проще и удобнее, раз уж требуют
6) Можем ли мы убедить заказчика отказаться от пагинации в таком виде?
с пятым пунктом не знаком
он. Но демаршалинг звучит круче! )
Вопрос о нужности/ненужности пагинации - это уже совсем другой вопрос. Если заказчик требует - куда деваться?
о какой проблемы вы говорите? Я не обещал решения этой проблемы в этой статье )
Спасибо большущее!