Должен ли я использовать курсоры SQL здесь?

Question

Я недавно прочитал о том, как следует избегать курсоров. Хорошо, я хотел бы знать, подходит ли их использование.

Я создаю механизм создания сценариев, который будет работать в Интернете (встроен в страницу, на стороне сервера). Этот скриптовый движок будет использоваться «продвинутыми» конечными пользователями этого продукта. Однако продукт работает очень сильно с базой данных, а язык сценариев C-like, но упрощен до того, где он также напоминает PHP. Для баз данных мне в основном нужен синтаксис, подобный этому, так как он является наиболее согласованным синтаксисом, созданным на языке, без того, чтобы конечный пользователь должен был писать код SQL (если мы собираемся заставить их сделать это, почему они не могут просто пропустить скриптовый движок, чтобы сделать жизнь проще). Синтаксис что-то вроде этого:

declare DataSet $data("tablename","OtherID="+$oid); 
//Dataset(string tablename,string where_clause_addon) 
$data["field1"]="the data of field... "; 
$data.Next(); 
$data["field1"]="The data of the next row"; 
$data[10]["field1"]="The data of the 10th row"; 

Я контролирую это внутренне, создавая глобальный курсор для каждого набора данных (я использую только 1 соединение в приложении), а затем давая глобальный курсор отслеживать положение в текущей строке (его также курсор SCROLL и UPDATE). Это делает мою жизнь намного проще, поскольку в противном случае я был бы вынужден писать свои собственные элементы управления SQL для борьбы с DataNeader.

Является ли это использование курсоров ОК одним? Обратите внимание, что страница с этими сценариями не будет доступна по всему миру, она будет доступна только для клиентов (возможно, только 3-10 пользователей одновременно).

Кто-нибудь видит лучший способ отслеживания текущего местоположения переменной? (поскольку они могут обращаться к таблицам с неизвестной схемой)

Кроме того, были ли у меня проблемы с параллелизмом с использованием курсоров, подобных этому? (Мои документы говорят, что курсоры являются глобальными для соединения, и каждый запрос страницы создает новое соединение на месте, поэтому пользователи не используют соединения)

Answer 1

«Я недавно прочитал о том, как следует избегать курсоров».

Их нельзя избежать.

«Я читал больше, что курсоры не обязательно следует избегать, а скорее, что курсоры медленны и должны использоваться только в определенных обстоятельствах».

Правильно - в определенных ситуациях.

Используйте операторы SQL, чтобы сделать как можно больше. Не изобретайте свою собственную логику обработки SELECT, открыв курсор и сделав кучу if-statements: используйте предложение WHERE. Не придумывайте свою собственную обработку GROUP-BY, открывая курсор и читайте каждую строку: используйте предложение GROUP BY. Не изобретайте свой собственный алгоритм объединения, используя вложенные контуры курсора: используйте правильное предложение JOIN.

Не изобретайте свой собственный SQL с помощью курсоров. Используйте SQL.

Как правило, пользователи «не используют курсоры» говорят «Не перерабатывайте алгоритмы SQL с помощью курсора». Это не широкий, смутный «не использовать курсоры». Это очень конкретный совет: «Изучите SQL, не работайте с пробелами в своих знаниях, написав петли курсора».

До тех пор, пока вы не заново изобретаете существующий алгоритм SQL, есть много вещей, для которых вы должны использовать использовать курсоры.

Не фетишизируйте «избегайте курсоров». Делайте фетишизацию, делая так же в «чистом SQL», насколько это разумно.

Не вступайте в преждевременную оптимизацию, поскольку вы отжимаете руки над программированием курсора/без курсора.Просто напишите лучший SQL, который вы можете, и сравнивайте производительность рано и часто.

Если вы не можете найти лучший SQL, спросите здесь о лучшем SQL - без фетишизации над курсорами.