Подсчёт строк в таблице вообще довольно дурацкое занятие. Возможно более грамотным будет изменить задачу, чтобы в этом не было необходимости. Например:
Как известно, в большинстве случаев в каждой таблице есть поле ID, которое используется как первичный ключ. Можно построить такую схему обновления данных в таблице, что пропусков в нумерации не будет, а если и будет, то только несколько штук, номера которых будут хранится в специальной таблице. Тогда задача подсчёта строк в таблице будет сводится к вызову max(ID) за вычетом count строк в таблице, хранящей удалённые номера.
Другой способ состоит в хранении счётчика записей таблицы в отдельной таблице. При добавлении записи, триггер добавляет единичку к счётчику, при удалении вычитает. Тогда вообще лафа, всё что нужно сделать - запросить значение счётчика.
Это не то, подсчет нужен для постраничной разбивки и выборка осуществляется по фильтру как бы если много фильтров то под каждую вариацию что то создавать не подходит.
Для постраничной разбивки ничего считать не надо.
Практически в любом языке программирования, когда вы выполняете запрос SELECT... чего-то там, после его завершения вы можете узнать количество возвращённых запросом записей.
При постраничной разбивке мне обязательно нужно знать общее количество строк поскольку с общего количества формируется количество страниц. Верно в практически любом языке есть функции возвращающие количество выбранных записей то ко вы не учли момент, что в выборке участвует limit и функция вернет количество лимита, а не полное количество строк. В mysql есть sql_calc_found_rows она возвращает количество выбранных строк без учета лимита одним запросом. Плохо что в постгри нет такого.
если вы возвращаете что-то с лимитом, то у вас количество строк, возвращённых запросом равно лимиту. Тогда и ясно что делать с постраничкой. Не понимаю, зачем при этом знать общее количество строк, ведь лимит возвращает только ПЕРВЫЕ строки и таким образом, получить, например 10-ю страницу с лимитом всё-равно не получится.
Лучше уж сделать, например, временный VIEW для этого запроса с дополнительным полем с пронумерованными записями, да крутить это дело как угодно.
Знать общее число строк нужно для того чтоб отобразить необходимое количество страниц. Например я не могу поставить количество пять страниц при том условии, что у меня их будет всего две это будет очень тупо.
Подсчёт строк в таблице
Подсчёт строк в таблице вообще довольно дурацкое занятие. Возможно более грамотным будет изменить задачу, чтобы в этом не было необходимости. Например:
Как известно, в большинстве случаев в каждой таблице есть поле ID, которое используется как первичный ключ. Можно построить такую схему обновления данных в таблице, что пропусков в нумерации не будет, а если и будет, то только несколько штук, номера которых будут хранится в специальной таблице. Тогда задача подсчёта строк в таблице будет сводится к вызову max(ID) за вычетом count строк в таблице, хранящей удалённые номера.
Другой способ состоит в хранении счётчика записей таблицы в отдельной таблице. При добавлении записи, триггер добавляет единичку к счётчику, при удалении вычитает. Тогда вообще лафа, всё что нужно сделать - запросить значение счётчика.
Это не то, подсчет нужен для
Это не то, подсчет нужен для постраничной разбивки и выборка осуществляется по фильтру как бы если много фильтров то под каждую вариацию что то создавать не подходит.
Для постраничной разбивки
Для постраничной разбивки ничего считать не надо.
Практически в любом языке программирования, когда вы выполняете запрос SELECT... чего-то там, после его завершения вы можете узнать количество возвращённых запросом записей.
При постраничной разбивке мне
При постраничной разбивке мне обязательно нужно знать общее количество строк поскольку с общего количества формируется количество страниц. Верно в практически любом языке есть функции возвращающие количество выбранных записей то ко вы не учли момент, что в выборке участвует limit и функция вернет количество лимита, а не полное количество строк. В mysql есть sql_calc_found_rows она возвращает количество выбранных строк без учета лимита одним запросом. Плохо что в постгри нет такого.
если вы возвращаете что-то с
если вы возвращаете что-то с лимитом, то у вас количество строк, возвращённых запросом равно лимиту. Тогда и ясно что делать с постраничкой. Не понимаю, зачем при этом знать общее количество строк, ведь лимит возвращает только ПЕРВЫЕ строки и таким образом, получить, например 10-ю страницу с лимитом всё-равно не получится.
Лучше уж сделать, например, временный VIEW для этого запроса с дополнительным полем с пронумерованными записями, да крутить это дело как угодно.
Знать общее число строк нужно
Знать общее число строк нужно для того чтоб отобразить необходимое количество страниц. Например я не могу поставить количество пять страниц при том условии, что у меня их будет всего две это будет очень тупо.
Тогда VIEW вам в руки, как я
Тогда VIEW вам в руки, как я и писал
это бредово, поскольку под
это бредово, поскольку под каждое значение фильтра создавать view когда вариантов может быть сотни...
ВРЕМЕННЫЙ view. Т.е. жить он
ВРЕМЕННЫЙ view. Т.е. жить он у вас будет до конца сессии. Могут быть и сотни: VIEW не таблица, места не занимает.
этот вариант был откинут еще
этот вариант был откинут еще с начала потому что это тупо, если есть дельное предложение рад выслушать, а фигню предлагать не надо