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

Question

У меня есть метод Paging, где он берет страницу и ограничивает, затем применяет их к заданному набору (может быть применен предварительный фильтр / запросы), затем он применяет нумерацию страниц, поэтому ничего не нужно делать в на стороне сервера от подсчета записей до применения нумерации страниц (учитывается только конечный результат, который все равно хранится в памяти)

        public async Task<PagingServiceResponse<T>> Apply<T>(IQueryable<T> set)
        {
            var httpQuery = _accessor.HttpContext.Request.Query;
            var pageValue = httpQuery.LastOrDefault(x => x.Key == "page").Value;
            if (pageValue.Count > 0) int.TryParse(pageValue, out _page);
            var limitValue = httpQuery.LastOrDefault(x => x.Key == "limit").Value;
            if (limitValue.Count > 0) int.TryParse(limitValue, out _limit);
            if (_limit > 1000 || _limit <= 0) _limit = 1000;
            if (_page <= 0) _page = 1;
            _size = await set.CountAsync();
            set = set.Take(_limit);
            if (_page > 1) set = set.Skip(_page * _limit);

            var data = await set.ToListAsync();
            var currentSize = data.Count;
            return new PagingServiceResponse<T>
            {
                Data = data,
                Size = _size,
                CurrentSize = currentSize,
                Page = _page,
                PerPage = _limit
            };
        }

Итак, проблема в том, что это дважды попадает в базу данных, чтобы проверить общее количество считать (CountAsync) и получать данные (ToListAsync)

, и я пытаюсь этого не делать, поскольку он выполняет запрос дважды, который не является чистым запросом, применяются операции фильтрации к нему.

Если есть какой-либо совет по поводу другого подхода или чего-то еще, я все уши.

Я использую PostgreSQL & ядро ​​структуры сущностей (npg sql)

Answer 1

Нет, вся предпосылка разбиения на страницы заключается в том, что вам нужно знать полное количество строк перед получением подмножества общих записей. Единственный способ сделать это за один запрос - это загрузить все записи. (Что является гораздо худшим вариантом для больших наборов!:)

Одна проблема, которую я вижу, состоит в том, что вы используете Take, чтобы взять предел строк (0 <= 1000?), А затем пропустить размер страницы и страница №? Для меня, если предел равен 1000, а размер вашей страницы равен 25, и вы загружаете первую страницу, разве это не вернет 1000 строк? (а не 25 на первой странице?) Обычно я ожидаю, что пейджинговый запрос будет действовать примерно так: </p>

var pagedData = set.Skip(page * pageSize).Take(pageSize).ToList();

Где page на основе 0. (0 = страница № 1). Это гарантирует, что только максимум 25 рядов отведены назад.

Некоторые действия, которые вы можете сделать, чтобы еще больше снизить стоимость запросов на нумерацию страниц и получение счетчика:

1. Структурируйте сборку и выполнение вашего запроса, чтобы упорядочивать и прогнозировать (Select / ProjectTo) происходит после получения Count.

2. Убедитесь, что контекст недолговечный и "fre sh". Это не ускорит подсчет, но загрузка подмножества будет выполняться медленнее, чем больше отслеживаемых объектов.

3. Если точное подсчет не требуется, предоставьте приблизительный подсчет который может быть расширен, когда пользователи выбирают дополнительную страницу, или может выбрать получение полного подсчета.

Получение приблизительного подсчета похоже на то, как поиск в Google дает приблизительное значение, а не реальное подсчет результатов. Относительно простая техника, которую я использую, это взять текущий размер страницы и количество страниц, отображаемых пейджером. Элемент управления нумерацией страниц должен быть настроен так, чтобы не отображалась навигация к странице «Последняя», а также должно быть скорректировано отображение количества записей.

Так, например, 10 страниц с размером страницы 25. Прежде чем получить счет, я основываю счет сверху ({PageSize} x {MaxPageCount} + 1) или 251. Чтобы получить maxPageCount, нам нужно посмотреть на номер страницы против числа ожидаемых страниц для отображения. (Т. Е. 10)

int maxPageCount = (((page) / 10)+1) * 10;
int roughCountLimit = pageSize * maxPageCount + 1;

rowCount = set.Take(roughCountLimit).Count();
bool isRoughCount = rowCount == roughCountLimit;
var pagedData = set.Skip(page * pageSize).Take(pageSize).ToList();

Для страниц с 1 по 10 Это вернет до 11 страниц. Т.е.

page #1 (0) / 10 = 0.  (0+1)* 10 = 10.
page #2 (1) / 10 = 0.  (0+1)* 10 = 10.
page #10 (9) / 10 = 0. (0+1)* 10 = 10.

Идея состоит в том, что пейджер будет отображать что-то вроде:

"1 2 3 4 5 6 7 8 9 10 ...", в то время как наш счетчик страниц будет настроен посмотреть на isRoughCount и отобразить: «250+» вместо «251», если isRoughCount равно True.

Если и когда пользователь выбирает «...» для загрузки страницы № 11, тогда возвращаясь к maxPageCount:

 page #11 (10) / 10 = 1. (1+1)* 10 = 20.

Это приведет к тому, что roughCountLimit станет 501. Это загрузит до 21 страницы записей. Если база данных возвращает только 251 запись, то она все равно будет отображаться с 1 оставшейся записью, а поскольку isRoughCount будет иметь значение false, счетчик строк обновится и отобразит «251». В противном случае счетчик страниц будет обновлен для отображения «500+». Если пользователь продолжает перемещаться по страницам, используя «...», приблизительный предел количества будет продолжать увеличиваться. Это сделает запрос постепенно медленнее, но для тех начальных нескольких наборов страниц запрос будет получать значения значительно быстрее.

Главное в разбивке на страницы и поиске заключается в том, что пользователи должны иметь инструменты для поиска данных, как правило, на первой странице, или, может быть, первые несколько страниц результатов. Фактическое количество раз, которое им потребуется для навигации по 10 страницам результатов, не говоря уже о 10 страницах результатов, должно быть почти никогда. (Это будет указанием на то, что вам нужны лучшие возможности поиска / фильтрации). В то же время, даже при действительно хорошем поиске, работающем с действительно большими наборами данных, пользователю, как правило, все равно, будет ли 5000 строк или 500 000 000 строк. Мы можем значительно ускорить выполнение запросов, сообщив, что «по крайней мере» 250 строк, а затем расширить их, если и только если это необходимо. Число страниц может быть отображено в виде гиперссылки для выполнения определенного c запроса с полным счетом, если они могут понадобиться, или просто интересует конкретное c 504 231 188 строк. Этот (дорогой) факт не обязательно должен быть частью каждого запроса.

Answer 2

Невозможно попасть в базу данных только один раз, чтобы получить как количество объектов, так и объекты. Если вы хотите сделать нумерацию страниц, оба запроса обязательны. Ссылка на похожий вопрос