Замена списка выбираемых полей на count(*) в SQL

Фанат

oncle terrible
Команда форума
WMix + with + case + over + udf :) я знаю

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

PHP:
$count_query = /*SELECT count(*) skipped */ "FROM T1 INNER JOIN bar on T1.f2!=bar.foo";
$data_query = 'WITH cte AS (SELECT foo FROM bar) SELECT f1, f2 from T1 where cte.foo != f2 ORDER BY f1' /* LIMIT :limit offset :offset will be added as agreement*/;
new Pagination($pdo, $count_query, $data_query);
ну так оно фактически так и делает, просто есть маленькая маггия для простых запросов
 

ksnk

прохожий
Библиотека, которая иногда, на некоторых запросах будет генерировать неправильный SQL и грохаться с ошибкой как-то не очень удачна, imho :)
Можно попытаться обеспечить работоспособность библиотеки при любых входных SQL. Просто отключить генерацию исключения в PDO при выполнении запроса-счетчика.
В случае, если произошла ошибка - ругаемся в лог или еще куда и тупо выполняем исходный запрос без лимита, подсчитывая счетчик вручную. При некоторой ловкости рук - можно результат запроса закэшировать, чтобы его еще раз не выполнять, если это, конечно, в природе возможно...
 

Valick

Новичок
ksnk, львиная (если не все) доля падений произойдёт на уровне написания и отладки кода. Это же "для бедных" и "лайт-вершин".
 
  • Like
Реакции: WMix

ksnk

прохожий
ksnk, львиная (если не все) доля падений произойдёт на уровне написания и отладки кода. Это же "для бедных" и "лайт-вершин".
Не все поддается отладке. Вообрази - сделался сайт, со страницей поиска по фильтрам, к нему прикрутили библиотечку и разработчик все проверил и радостно потирая ручки удалился в светлую даль. Через некоторое время потребовался новый комплект фильтров, вроде все просто - добавь условия в sql... Что может пойти не так ?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
главный вопрос - стоит ли изучение этой тулзы экономии сил на написание ручками count-запроса
 

WMix

герр M:)ller
Партнер клуба
На самом деле мотивация понятна, таблица огромная, ищем оптимальные пути.
я к тому что если уж делать то делать для всего, и только для особых случаев исключения.
ну и был бы для всех случаев select count(*) from (sql), а для особых, где запрос простой, но скорость узкое место с заменой полей.
это вроде достаточно прозрачно.
написании ручками count-запроса
простой не всегда короткий, и вместо дублирования логики построения запроса иметь готовый инструмент, будет удобнее
что там изучать?
 

fixxxer

К.О.
Партнер клуба
Можно попытаться обеспечить работоспособность библиотеки при любых входных SQL
Очевидно, это возможно только в двух случаях:
1) query builder, который сам строит известное ему подмножество sql, так уже сделано в том же laravel
2) полноценный парсер sql в ast

Регулярками не стоит даже пытаться.

On a side note, я не вижу особого смысла в generic пагинаторе, манипулирующем sql. Для простых запросов есть query builder. С трехэтажными же зачастую и с большим offset-ом будут проблемы с производительностью, и в таких случаях делается не пагинатор, а всякие там show more. Да и даже если не так, тот, кто способен написать эффективный трехэтажный запрос, уж точно в состоянии и пагинатор к этому приделать.
 
Последнее редактирование:

weregod

unserializer
Оффтоп, на днях пришлось изучить китайский QB, так гордился собой и чутка похвасталсо перед заказчиком, а потом оказалось, что inner join убивает ф-л, понял, что в драйвере конкретной БД лучше руками ((
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
и как в анекдоте про выходим назад на Дерибасовскую - возвращаемся к применимости решения в частном случае автогенерации CRUD, что уже реализовано
 
Сверху