Новое сообщение в форум Базы данных

Форум	Базы данных
Тема	Как правильно задавать вопросы

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Здравствуйте, wildwind, Вы писали:

N_P>>>Поточно - не нравится привязка к framework, с которым с БД работаю (сейчас C# ADO.NET). 
W>>Поясни, пожалуйста, о какой привязке идет речь.

N_P>Библиотеки, которыми я пользуюсь для решения этой задачи (как раз пейджинг и реализуют) есть только под C# ADO.NET.
N_P>Если же я неправильно понял вопрос и речь просто про чтение данных к уже исполненному на сервере полному запросу - то здесь я пока с проблемами не сталкивался. Тут все ясно - чтение пачками некоей длинны и передача дальше на обработку.

N_P>>>А таймауты расширять дело плохое. Или на большой запрос времени не хватит или посыпятся жалобы на то, что при отвале БД об ошибке программа сообщит только через полчаса.
W>>Никто же не предлагает один таймаут на все случаи жизни, будь он большим или маленьким. Они для того и настраиваются, чтобы применять их разумно, по ситуации.

N_P>Так проблема в том, что никто не знает времени исполнения произвольного запроса до его исполнения. Мы не можем настроить правильный таймаут заранее. Мы можем сделать его разумно большим, но в этом - свои неприятности. Подробнее - ниже.

N_P>>>Вообще - я почему именно сюда, а не в .NET тему, такой вопрос написал? Я подумал, что дело это, чтение больших выборок, не редкое, те же grid для вывода больших данных есть аналогичная задача. И что есть уже наработанные и проверенные паттерны этой задачи решения.
W>>Большая выборка в гриде - это совсем другой случай. Как правило, это свидетельство неумелого проектирования UI. Но для остальных случаев проверенный паттерн - это пейджинг, с разными способами и степенью его поддержки в СУБД и фреймворках.

N_P>Именно этот вариант сейчас в работе. Правда, на сторонних библиотеках. Есть ли варианты кроме пейджинга? Какие есть варианты read only forward only paging? Зря я, наверное, слишком общий вопрос задал - спросил бы сразу про виды и альтернативы пейджингу.

W>>Для меня все еще непонятна проблема, для которой ищется "общее решение". Если ты где-то услышал или прочитал мантру "долгие запросы это очень плохо, нужно их избегать или бить на части", то не нужно воспринимать ее как догму, а оценивать с умом по конкретной ситуации. Для интерактивной работы да, это плохо, так как важно время отклика, которое страдает от долгих запросов. А для пакетной обработки подход другой. Тут важна пропускная способность, а время отклика мало кого волнует.

N_P>Проблема - управляемое чтение больших массивов данных. Не в смысле количества байт, а в смысле числа строк. И мне показалось изначально разумным, что все сразу мы не получим и запрос будет разбит на подзапросы. Именно из-за требования больших таймаутов для исполнения большого запроса. Потому что практика показывает, что большой таймаут несет проблемы с реакцией оператора (не только в GUI), трудностями в отмене операции, трудностями в реагировании на сбои (понять, что отвалился сервер желательно как можно раньше, а у нас таймаут - час), трудностями с блокировкой ресурсов БД и отъеданием ресурсов сервера БД. Пейджинг - один из вариантов решения, но он больше на Grid ориентирован. Курсоры, как учат нас книги и интернет - вселенское тормозное зло. Что применять?

W>>>>1. Обрабатывать на сервере (с помощью SQL или ХП).
N_P>>>А как? Что по этому поводу почитать и где посмотреть пример?
W>>Зависит от задачи и алгоритма. Если конечным результатом обработки миллиона строк является тысяча строк или сотня, то лучше сделать это на сервере, поближе к исходным данным, чтобы не тратить время на перекачку их по сети. Конечная выборка получится уже небольшая.

N_P>Ну, это как-бы понятно :-)

W>>Почитать - документацию по СУБД, там и примеры есть. Ну и на книжку вон ссылку уже кинули.

N_P>В документации про пейджинг точно нет. И, судя по тому, что ссылка была даже без указания главы в книге - это просто посыл на "RTFM".

W>>>>2. Обрабатывать на клиенте, не помещая все в память.
N_P>>>В память вполне можно получить полный ID записей.
W>>Не понял?

N_P>Обычно нужен не вообще запрос, а выборка из таблицы с условиями. В этих случаях можно получить все ключи записей в память, а потом читать данные пачками. Случай частный, но частый.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail