Категорически приветствую!
Всегда пользовался практически неизменным паттерном для постраничного вывода, но вот встала задача выводить данные из таблицы в которой при определенных условиях может оказаться огромное количество записей, вот тут то и затык. Ниже код:
create procedure getDataByPage
@pageNumber int,
@itemsPerPage int,
@field1 char(16) = null,
@field2 char(16) = null,
@field3 char(16) = null,
@totalCount int = null output
as
begin
declare @startRow int;
set @startRow = itemsPerPage * (pageNumber - 1);
declare @matchedData (Id int primary key, rowNumber int);
set nocount off;
insert into @matchedData(Id, rowNumber)
select top(@itemsPerPage * @pageNumber)
d.id,
row_number() over (order by d.id desc) as rowNumber
from data d
where (@field1 is null or field1 = @field1)
and (@field2 is null or field2 = @field2)
and (@field3 is null or field3 = @field3)
order by p.id desc
-- Общее количество найденных записей
set @totalCount = @@rowcount;
set nocount on;
select d.id, d.field1, d.field2, d.field3, t1.something1, t2.something2
from data d
join table1 t1 on t1.field1 = d.field1
join table1 t2 on t2.field2 = d.field2
where d.id in (select top(@itemsPerPage) id from @matchedData where rowNumber > @startRow)
end
Клиенту нужно отдавать общее количество записей попавших под фильтр, раньше, когда ранжировалось относительно маленькое количество записей в первой помеченной строчке не было TOP, и все работалос правильно, а сейчас получается так что в @totalCount записывается просто @ItemsPerPage * @pageNumber. т.е. нужно делать отдельный select @totalCount = count(*), а это не так быстро. Может быть есть какое-нибудь «элегантное» решение, кроме как оптимизировать выборку количества, чтобы она летала?
С одной стороны я понимаю, что задача «высосана из пальца» и на самом деле вряд-ли кто-то полезет на 20546 страницу, но... интересно услышать ваши мысли
----
Think twice before you press F5.