Why use cursor and for loop?

Question

Hi All
So in general why would we use a cursor and a for loop to do update in a stored procedure?
Why wouldnt we just use a single update statement ?
is there compelling reason for using a cursor and a for loop: I am reading some code from a co-worker that the business logic for the select (set need to be updated) is complex but the update logic is simple (just set a flag to (0 or 1 or 2 or 3 or 4).
But eventually the select come down to a key (row_id) so I re-write it using just a single sql statement.
The size of the main table is about 2.6 to 3million rows
Any thoughts on that??
The code below I just do a google for cursor for update example in case for something to play with
-Thanks for all your input
create table f (a number, b varchar2(10));
insert into f values (5,'five');
insert into f values (6,'six');
insert into f values (7,'seven');
insert into f values (8,'eight');
insert into f values (9,'nine');
commit;
create or replace procedure wco as
  cursor c_f is
    select a,b from f where length(b) = 5 for update;
    v_a f.a%type;
    v_b f.b%type;
begin
  open c_f;
  loop
    fetch c_f into v_a, v_b;
    exit when c_f%notfound;
    update f set a=v_a*v_a where current of c_f;
  end loop;
  close c_f;
end;
exec wco;
select * from f;
drop table f;
drop procedure wco;
Joining multiple tables
create table numbers_en (
  id_num  number        primary key,
  txt_num varchar2(10)
insert into numbers_en values (1, 'one'  );
insert into numbers_en values (2, 'two'  );
insert into numbers_en values (3, 'three');
insert into numbers_en values (4, 'four' );
insert into numbers_en values (5, 'five' );
insert into numbers_en values (6, 'six'  );
create table lang (
   id_lang   char(2) primary key,
   txt_lang  varchar2(10)
insert into lang values ('de', 'german');
insert into lang values ('fr', 'french');
insert into lang values ('it', 'italian');
create table translations (
  id_num    references numbers_en,
  id_lang   references lang,
  txt_trans varchar2(10) not null
insert into translations values (1, 'de', 'eins'   );
insert into translations values (1, 'fr', 'un'     );
insert into translations values (2, 'it', 'duo'    );
insert into translations values (3, 'de', 'drei'   );
insert into translations values (3, 'it', 'tre'    );
insert into translations values (4, 'it', 'quattro');
insert into translations values (6, 'de', 'sechs'  );
insert into translations values (6, 'fr', 'six'    );
declare
  cursor cur is
      select id_num,
             txt_num,
             id_lang,
             txt_lang,
             txt_trans
        from numbers_en join translations using(id_num)
                   left join lang         using(id_lang)
    for update of translations.txt_trans;
  rec cur%rowtype;
begin
  for rec in cur loop
    dbms_output.put (
      to_char (rec.id_num         , '999') || ' - ' ||
      rpad    (rec.txt_num        ,   10 ) || ' - ' ||
      rpad(nvl(rec.txt_trans, ' '),   10 ) || ' - ' ||
               rec.id_lang                 || ' - ' ||
      rpad    (rec.txt_lang       ,   10 )
    if mod(rec.id_num,2) = 0 then
      update translations set txt_trans = upper(txt_trans)
       where current of cur;
       dbms_output.put_line(' updated');
    else
      dbms_output.new_line;
    end if;
  end loop;
end;
/Edited by: xwo0owx on Apr 25, 2011 11:23 AM

Answer 1

Adding my sixpence...
PL/SQL is not that different from a SQL perspective than any other SQL client language like Java or C# or C/C++. PL/SQL simply integrates the 2 languages a heck of a lot better and far more transparent than the others. But make no mistake in that PL/SQL is also a "client" language from a SQL perspective. The (internal) calls PL/SQL make to the SQL engine, are the same (driver) calls made to the SQL engine when using Java and C and the others.
So why a cursor and loops in PL/SQL? For the same reason you have cursors and loops in all these other SQL client languages. There are the occasion that you need to pull data from the SQL engine into the local language to perform some very funky and complex processing that is not possible using the SQL language.
The danger is using client cursor loop processing as the norm - always pulling rows into the client language and crunching it there. This is not very performant. And pretty much impossible to scale. Developers in this case views the SQL language as a mere I/O interface for reading and writing rows. As they would use the standard file I/O read() and write() interface calls.
Nothing could be further from the truth. SQL is a very advance and sophisticated data processing language. And it will always be faster than having to pull rows to a client language and process them there. However, SQL is not Turing complete. It is not the procedural type language that most other languages we use, are. For that reason there are things that we cannot do in SQL. And that should be the only reason for using the client language, like PL/SQL or the others, to perform row crunching using a client cursor loop.