Здравствуйте, wildwind, Вы писали:
N_P>>Поточно — не нравится привязка к framework, с которым с БД работаю (сейчас C# ADO.NET).
W>Поясни, пожалуйста, о какой привязке идет речь.
Библиотеки, которыми я пользуюсь для решения этой задачи (как раз пейджинг и реализуют) есть только под C# ADO.NET.
Если же я неправильно понял вопрос и речь просто про чтение данных к уже исполненному на сервере полному запросу — то здесь я пока с проблемами не сталкивался. Тут все ясно — чтение пачками некоей длинны и передача дальше на обработку.
N_P>>А таймауты расширять дело плохое. Или на большой запрос времени не хватит или посыпятся жалобы на то, что при отвале БД об ошибке программа сообщит только через полчаса.
W>Никто же не предлагает один таймаут на все случаи жизни, будь он большим или маленьким. Они для того и настраиваются, чтобы применять их разумно, по ситуации.
Так проблема в том, что никто не знает времени исполнения произвольного запроса до его исполнения. Мы не можем настроить правильный таймаут заранее. Мы можем сделать его разумно большим, но в этом — свои неприятности. Подробнее — ниже.
N_P>>Вообще — я почему именно сюда, а не в .NET тему, такой вопрос написал? Я подумал, что дело это, чтение больших выборок, не редкое, те же grid для вывода больших данных есть аналогичная задача. И что есть уже наработанные и проверенные паттерны этой задачи решения.
W>Большая выборка в гриде — это совсем другой случай. Как правило, это свидетельство неумелого проектирования UI. Но для остальных случаев проверенный паттерн — это пейджинг, с разными способами и степенью его поддержки в СУБД и фреймворках.
Именно этот вариант сейчас в работе. Правда, на сторонних библиотеках. Есть ли варианты кроме пейджинга? Какие есть варианты read only forward only paging? Зря я, наверное, слишком общий вопрос задал — спросил бы сразу про виды и альтернативы пейджингу.
W>Для меня все еще непонятна проблема, для которой ищется "общее решение". Если ты где-то услышал или прочитал мантру "долгие запросы это очень плохо, нужно их избегать или бить на части", то не нужно воспринимать ее как догму, а оценивать с умом по конкретной ситуации. Для интерактивной работы да, это плохо, так как важно время отклика, которое страдает от долгих запросов. А для пакетной обработки подход другой. Тут важна пропускная способность, а время отклика мало кого волнует.
Проблема — управляемое чтение больших массивов данных. Не в смысле количества байт, а в смысле числа строк. И мне показалось изначально разумным, что все сразу мы не получим и запрос будет разбит на подзапросы. Именно из-за требования больших таймаутов для исполнения большого запроса. Потому что практика показывает, что большой таймаут несет проблемы с реакцией оператора (не только в GUI), трудностями в отмене операции, трудностями в реагировании на сбои (понять, что отвалился сервер желательно как можно раньше, а у нас таймаут — час), трудностями с блокировкой ресурсов БД и отъеданием ресурсов сервера БД. Пейджинг — один из вариантов решения, но он больше на Grid ориентирован. Курсоры, как учат нас книги и интернет — вселенское тормозное зло. Что применять?
W>>>1. Обрабатывать на сервере (с помощью SQL или ХП).
N_P>>А как? Что по этому поводу почитать и где посмотреть пример?
W>Зависит от задачи и алгоритма. Если конечным результатом обработки миллиона строк является тысяча строк или сотня, то лучше сделать это на сервере, поближе к исходным данным, чтобы не тратить время на перекачку их по сети. Конечная выборка получится уже небольшая.
Ну, это как-бы понятно
W>Почитать — документацию по СУБД, там и примеры есть. Ну и на книжку вон ссылку уже кинули.
В документации про пейджинг точно нет. И, судя по тому, что ссылка была даже без указания главы в книге — это просто посыл на "RTFM".
W>>>2. Обрабатывать на клиенте, не помещая все в память.
N_P>>В память вполне можно получить полный ID записей.
W>Не понял?
Обычно нужен не вообще запрос, а выборка из таблицы с условиями. В этих случаях можно получить все ключи записей в память, а потом читать данные пачками. Случай частный, но частый.
