Недостатки Sql Cursor

Question

Я изучал курсор и где-то читал, что. Каждый раз, когда вы выбираете строку из курсора, это приводит к круговому обходу сети, тогда как обычный запрос на выборку выполняет только один круговой обход, каким бы большим не был результат.Кто-нибудь может объяснить, что это значит?А что означает сеть туда и обратно и одна поездка туда и обратно, подробно описывает пример.И когда мы используем курсор и когда мы используем цикл while?

Answer 1

К сожалению, эта ссылка неверна.

«Нормальный SELECT» создает курсор, из которого клиент выбирает.Механика точно такая же, как если бы вы открывали и возвращали SYS_REFCURSOR (или любой другой механизм для открытия курсора).В обоих случаях клиент будет извлекать ряд строк по сети каждый раз, когда запрашивает данные из базы данных.Клиент может контролировать количество строк, которые выбираются каждый раз - для клиента было бы крайне редко выбрать 1 строку или извлечь все строки из курсора в одном круговом обходе сети.

Что на самом деле происходит, когда клиентское приложение выбирает из курсора (независимо от того, как курсор открывается), клиентское приложение отправляет запрос по сети на N строк (опять же, клиент контролирует значение N).База данных отправляет следующие N строк обратно клиенту (как правило, Oracle должен продолжить выполнение запроса, чтобы определить следующие N строк, потому что Oracle обычно не материализует весь набор результатов).Клиентское приложение что-то делает с этими N строками, а затем отправляет другой запрос по сети на следующие N строк, и шаблон повторяется.

Answer 2

Практически во всех системах баз данных приложение, использующее данные; и СУБД, которая отвечает за хранение и поиск данных; живу на отдельных машинах. Они разговаривают друг с другом по сети. Даже если они находятся на одной и той же машине, сетевое соединение остается эффективным.

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

Когда вы делаете запрос для всего набора данных, вы оплачиваете эту стоимость только один раз; Хотя это может показаться расточительным; на самом деле гораздо эффективнее взять на себя бремя удержания всех данных в приложении, поскольку обычно проще выделить больше ресурсов приложению, чем сделать то же самое на сервере базы данных.

Когда ваше приложение извлекает данные только по одной строке за раз, тогда стоимость двусторонней связи между приложением и базой данных оплачивается один раз за строку; Если вы хотите показать заголовки 100 постов в блоге, то вы платите 100 поездок туда и обратно в базу данных для этого одного отчета. Что еще хуже, сервер баз данных должен каким-то образом отслеживать частично завершенный набор результатов. Обычно это означает, что ресурсы, которые могут быть использованы для запроса данных для другого запроса, вместо этого сохраняются приложением, которому не удалось запросить все данные, которые первоначально запрашивалось.

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