A "rule-of-thumb" to get blazing speed in a database is to use set-based commands instead of separate procedural style commands. It's not only the network round trips that affect performance. Even if you have the loop embedded in the sql, you'll find it orders of magnitude slower than a set-based command.

--SLOW way, procedural
loop i=0 to 999999
    update foobar set status='test' where id=i;
end loop

vs

--FAST way, set-based
update foobar set status='test' where id between 0 and 999999

Just identify the bottle necks. You can keep the rest of the logic controlled with your objects. If you operate on a single record at a time, the procedural style is just as fast.

A "rule-of-thumb" to get blazing speed in a database is to use set-based commands instead of separate procedural style commands. It's not only the network round trips that affect performance. Even if you have the loop embedded in the sql, you'll find it orders of magnitude slower than a set-based command.

--SLOW way, procedural
loop i=0 to 999999
    update foobar set status='test' where id=i;
end loop

vs

--FAST way, set-based
update foobar set status='test' where id between 0 and 999999

Anywhere you see data processed in a loop, you can replace it with set-based commands. If there are changing conditions checked mid-loop then you may be forced to use procedural style. But that is very rare.

Just identify the bottle necks. You can keep the rest of the logic controlled with your objects. If you only operate on a single record, the procedural style is just as fast.

NOTE: internally within the RDBMS the "set-based" commands are executed via a procedural loop. Nothing wrong with loops per-say, it's just the interface provided by most RDBMS's are optimized to be used with set-based commands.