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