Как не дать пользователю заснуть во время загрузки большого набора данных

[dimyanchek]

Решение не ново и даже очевидно ,тут вы не удивили ни разу, но за детали реализации большое спасибо, весьма полезно.

[OkunevPY]

Решение не просто не ново, оно старо как мир.

И уже давно на вопрос как грузить данные ответили простым подходом, разделяй и влавствуй. Например разбить бд на кусочки, и не дрюгать всю бд целиком, а выполнить n+1 запрос к разным частям данных? Профит мне кажеться куда больше чем грузить из одного источника кусками.

[leksiq]

На мой взгляд, ORM всё же завязан на БД, предполагает достаточно прямое соответствие модели и таблиц. Не всегда это возможно. В моём случае используется унаследованная БД, довольно запутанная, но стоит задача совместимости старой и новой системы в течение долгого периода. Также, на мой взгляд, в вашем случае будут происходить отдельные запросы БД вместо одного. Также, данные могут приходить не только из БД. Например, файловая система или учетная запись IMAP...

[Android97]

Почему нельзя просто по страницам вытаскивать данные из БД и передавать клиенту ?
Если ORM используете то будет примерно так: cats.Skip(pageNumber * pageSize).Take(pageSize)
И каждый раз дополнительно высылать общее количество строк в БД. Итого, клиент сам будет запрашивать нужную порцию данных.

[leksiq]

На мой взгляд, ORM всё же завязан на БД, предполагает достаточно прямое соответствие модели и таблиц. Не всегда это возможно. В моём случае используется унаследованная БД, довольно запутанная, но стоит задача совместимости старой и новой системы в течение долгого периода. Также, на мой взгляд, в вашем случае будут происходить отдельные запросы БД вместо одного. Также, данные могут приходить не только из БД. Например, файловая система или учетная запись IMAP...

[Android97]

Про ORM это только пример :) Можно то же самое сделать SQL запросом (см. LIMIT и OFFSET).Про IMAP сказать ничего не могу, не решал такую задачу.

[trueMoRoZ]

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

Если сделать ленивые вычисления, то будет один запрос

[leksiq]

Хорошо, спасибо.

[qw1]

stateful-сервер сомнительное удовольствие. Сразу минус масштабирование, а когда это всё обрастёт кодом, не перепишешь уже. Я встречал вариант, когда первый запрос отдаёт только id-шники строк, которые попадают под фильтры, дальше клиент сам разбивает этот список на куски и запросиками по 200-500 id загружает полноценные объекты со всеми внутренностями.

[xFFFF]

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

[qw1]

Например, пользователь нажмёт «сортировать по столбцу» — и приехали, надо загрузить всё. Вообще очень сложно переучивать пользователей, они привыкли в старой системе видеть 100500 записей, и хотят всё то же самое в новой, и не хотят объяснять, зачем им эти 100500 строк для их задачи.

[xFFFF]

Так отправляешь новый запрос в бд, и возвращаешь уже отсортированный результат, который так же подгружаешь по мере прокрутки. Время отклика приложения получается намного меньше, и бд не насилуется.

[qw1]

Слишком сложно в реализации.

Когда все данные на клиенте, их нужно фильтровать/сортировать локально, а когда не всё загружено, то обращаться к серверу при изменениях в порядке сортировки.

Опять же, начинается с того, что юзеры хотят видеть свои заказы за день (порядка 10 штук) и программист всё загружает на клиент, и делает всё как можно проще. А в конце квартала хотят видеть за весь период, да ещё от всех менеджеров, а 100500 часов времени не дают, чтобы полноценно переписать под этот сценарий, и получается как получается.

[0x131315]

Эм, это же классическая задача вывода листинга. Решается через отдельный интерфейс с пагинацией. Обычно он же поддерживает сортировку, в том числе по нескольким произвольным полям. Работает быстро как раз за счёт того, что лишние данные реально не запрашиваются, даже на уровне БД. Зачем тут велосипед - решительно непонятно.