Результаты поиска

Представьте себе сцену, вы обновляете какой-то устаревший код Sybase и натыкаетесь на курсор. Хранимая процедура создает результирующий набор в таблице #temporary, которая полностью готова к возвращению, за исключением того, что один из столбцов не очень удобочитаем, это буквенно-цифровой код.

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

declare c_lookup_codes for
select distinct lookup_code
from #workinprogress

while(1=1)
begin
    fetch c_lookup_codes into @lookup_code

    if @@sqlstatus<>0
    begin
        break
    end

    exec proc_code_xref @lookup_code @xref_code OUTPUT

    update #workinprogress
    set xref = @xref_code
    where lookup_code = @lookup_code
end

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

_NB: для целей этого примера вы также можете представить, что результирующий набор находится в области 500k строк и что существует 100 различных значений look_up_code и, наконец, что невозможно иметь таблицу со значениями внешней ссылки, так как логика в proc_code_xref слишком arcane._

При написании запросов к базе данных в чем-то вроде TSQL или PLSQL у нас часто есть выбор: перебирать строки курсором для выполнения задачи или создавать один оператор SQL, который выполняет одну и ту же работу одновременно.

Кроме того, у нас есть возможность просто вытащить большой набор данных обратно в наше приложение и затем обработать его строка за строкой, с помощью C#, Java, PHP или чего-то еще.

Почему лучше использовать запросы на основе наборов? Какая теория стоит за этим выбором? Каков хороший пример решения на основе курсора и его реляционного эквивалента?