Чому люди так ненавидять курсори SQL? [зачинено]

Я можу зрозуміти, що хочу уникнути необхідності використання курсору через накладні витрати і незручності, але схоже, що існує якась серйозна манія курсору-фобії, де люди збираються з великими зусиллями, щоб уникнути їх використання.

Наприклад, одне запитання задало, як зробити щось очевидно тривіальне за допомогою курсору та прийняту відповідь, запропоновану за допомогою рекурсивного запиту загальної таблиці (CTE) з рекурсивною спеціальною функцією, хоча це обмежує кількість рядків, які можна обробити до 32 (через обмеження рекурсивної функції виклику на сервері sql). Це вражає мене жахливим рішенням для довголіття системи, не кажучи вже про величезні зусилля, щоб уникнути використання простого курсору.

У чому причина такого рівня шаленої ненависті? Хтось із «помічених авторитетів» видав фетву проти курсорів? Чи якесь невимовне зло ховається в серці курсорів, що розбещує мораль дітей чи щось таке?

Питання Wiki, більше зацікавлене у відповіді, ніж відповідь.

Інформація про те:

Курсори швидкого переходу вперед SQL Server

EDIT: дозвольте бути більш точним: я розумію, що курсори не слід використовувати замість звичайних реляційних операцій ; це нереалізатор. Що я не розумію, це те, що люди відмовляються від шляху, щоб уникнути курсорів, як-от у них є печиво чи щось подібне, навіть коли курсор є більш простим та / або більш ефективним рішенням. Мене бентежить нераціональна ненависть, а не очевидна технічна ефективність.

"Накладні витрати" з курсорами - лише частина API. Курсори - це те, як частини RDBMS працюють під кришкою. Часто CREATE TABLEі INSERTєSELECT заяви, і реалізація є очевидним внутрішнім курсором реалізації.

Використовуючи "оператори на основі набору", зв'язує результати курсору в єдиний набір результатів, що означає менше API назад і вперед.

Курсори передують сучасним мовам, які пропонують першокласні колекції. Старі C, COBOL, Fortran тощо повинні були обробляти рядки по одному, оскільки не було поняття "колекція", яке можна було б широко використовувати. У Java, C #, Python та ін. Є структури першокласного списку, які містять набори результатів.

Повільний випуск

У деяких колах реляційні приєднання є загадкою, і люди будуть писати вкладені курсори, а не просте з'єднання. Я бачив по-справжньому епічні операції вкладеного циклу, виписані у вигляді безлічі курсорів. Поразка оптимізації RDBMS. І біжить справді повільно.

Прості SQL переписуються, щоб замінити вкладені петлі курсору приєднаннями, а одна, плоска петля курсору, може змусити програми запускатись у 100-й раз. [Вони думали, що я бог оптимізації. Все, що я зробив, було замінити вкладені петлі з'єднаннями. Ще використовуються курсори.]

Ця плутанина часто призводить до звинувачення у кримінальних справах. Однак це не курсор, це неправильне використання курсору.

Випуск розміру

Для дійсно епічних наборів результатів (тобто, перекидання таблиці у файл) курсори є важливими. Операції на основі набору не можуть реалізувати дійсно великі набори результатів як єдину колекцію в пам'яті.

Альтернативи

Я намагаюся максимально використовувати шар ORM. Але це має дві цілі. По-перше, курсорами керує компонент ORM. По-друге, SQL відокремлюється від програми в файл конфігурації. Справа не в тому, що курсори погані. Справа в тому, що кодування всіх відкритих, закритих і витягуваних програм не є додатковою програмою.

Курсори змушують людей надмірно застосовувати процедурний спосіб мислення до встановленого середовища.

І вони РОЗУМНІ !!!

Від SQLTeam :

Зауважте, що курсори - це НАЙСЛОВНІший спосіб доступу до даних всередині SQL Server. Це слід використовувати лише тоді, коли вам справді потрібно мати доступ до одного рядка за раз. Єдина причина, про яку я можу подумати, - це викликати збережену процедуру в кожному рядку. У статті про ефективність курсору я виявив, що курсори втридцять разів повільніше, ніж встановлені альтернативи .

Вище є відповідь, в якій сказано, що "курсори - НАЙСЛОВНІший спосіб доступу до даних всередині SQL Server ... курсори більш ніж у тридцять разів повільніші, ніж встановлені альтернативи".

Це твердження може бути істинним за багатьох обставин, але, як істинне твердження, це проблематично. Наприклад, я добре застосував курсори в ситуаціях, коли я хочу виконати операцію оновлення або видалення, що впливає на багато рядків великої таблиці, яка отримує постійне зчитування виробництва. Запуск збереженої процедури, яка робить ці оновлення один рядок, за часом стає швидшим, ніж операції на основі заданих, оскільки операція на основі набору конфліктує з операцією зчитування і закінчується причиною жахливих проблем із блокуванням (і може повністю знищити виробничу систему, в крайніх випадках).

За відсутності іншої діяльності з базами даних, операції на основі заданих програм є універсально швидшими. У виробничих системах це залежить.

Курсори, як правило, використовуються для запуску розробників SQL в тих місцях, де операції на основі набору були б кращими. Зокрема, коли люди вивчають SQL після вивчення традиційної мови програмування, менталітет "повторення цих записів" має тенденцію змусити людей використовувати неправильно використовувати курсори.

Більшість серйозних книг SQL включає в себе розділ, що користується курсорами; добре написані чітко дають зрозуміти, що курсори мають своє місце, але їх не слід використовувати для встановлених операцій.

Очевидно, є ситуації, коли курсори - правильний вибір, або принаймні правильний вибір.

Оптимізатор часто не може використовувати реляційну алгебру для перетворення проблеми, коли використовується метод курсору. Часто курсор - це чудовий спосіб вирішити проблему, але SQL - це декларативна мова, і в базі даних багато інформації, від обмежень, до статистики та індексів, що означає, що оптимізатор має багато варіантів вирішення проблеми Проблема, тоді як курсор в значній мірі прямо спрямовує рішення.

У Oracle PL / SQL курсори не призведуть до блокування таблиць, і можливо використовувати масовий збір / груповий збір.

В Oracle 10 часто використовується неявний курсор

  for x in (select ....) loop
    --do something 
  end loop;

отримує неявно 100 рядків одночасно. Можливий також явний збір об'ємної маси / об'ємний збір.

Однак курсори PL / SQL - це крайня можливість, використовуйте їх, коли ви не можете вирішити проблему з набором SQL.

Інша причина - паралелізація, для бази даних простіше паралелізувати великі оператори на основі набору, ніж імперативний код рядка за рядком. Це та сама причина, чому функціональне програмування стає все більш популярним (Haskell, F #, Lisp, C # LINQ, MapReduce ...), функціональне програмування полегшує паралелізацію. Кількість процесорів на комп'ютері зростає, тому паралелізація стає все більшою проблемою.

Взагалі, тому що у реляційній базі даних продуктивність коду за допомогою курсорів на порядок гірше, ніж операції на основі заданих даних.

Наведені відповіді недостатньо підкреслили важливість блокування. Я не великий фанат курсорів, оскільки вони часто призводять до блокування рівнів таблиці.

Для чого варто прочитати, що курсор "єдиного" місця виконуватиме свій аналог на основі заданих значень. У невеликій таблиці швидкість підсумовування рядків над порядком за стовпцями сприяє операції на основі набору, але в міру збільшення таблиці в розмірі рядків курсор стане швидшим, оскільки він може просто перенести поточне загальне значення до наступного проходу петля. Тепер, де вам слід виконати загальну суму - це інший аргумент ...

Я згоден із статтею на цій сторінці:

http://weblogs.sqlteam.com/jeffs/archive/2008/06/05/sql-server-cursor-removal.aspx

Поза виконанням (не) питань, я думаю, що найбільша помилка курсорів полягає в тому, що вони болючі налагодження. Особливо порівняно з кодом у більшості клієнтських додатків, де налагодження є порівняно простим, а мовні функції, як правило, набагато простішими. Насправді я стверджую, що майже все, що робиться в SQL з курсором, мабуть, має відбуватися в клієнтській програмі в першу чергу.

Чи можете ви опублікувати цей приклад курсору чи посилання на запитання? Можливо, є навіть кращий спосіб, ніж рекурсивний CTE.

Крім інших коментарів, курсори при неправильному використанні (що часто) викликають непотрібні блокування сторінок / рядків.

Можливо, ви могли б закінчити своє запитання після другого абзацу, а не називати людей "божевільними", просто тому, що вони мають іншу точку зору, ніж ви, і в іншому випадку намагаєтесь знущатися над професіоналами, які можуть мати дуже вагомі причини відчувати себе так, як вони роблять.

Що стосується вашого питання, хоча, звичайно, є ситуації, коли курсор може бути викликаний, але, на мій досвід, розробники вирішують, що курсор "повинен" використовуватися FAR частіше, ніж є насправді. Шанс того, що хтось помилиться на стороні занадто великого використання курсорів проти їх використання, коли вони повинні, НАБАГО вище на мою думку.

в основному 2 блоки коду, які роблять те саме. можливо, це трохи дивний приклад, але це доводить суть. SQL Server 2005:

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

одиночне оновлення займає 156 мс, тоді як курсор займає 2016 мс.