Unlike Oracle?!?!?! The idea that Oracle runs perfectly fine with cursors is a complete fiction! What is true is that Oracle (the company) doesn't make as big a deal of it as Microsoft does, and consequently almost no Oracle books even mention the fact that cursors are performance killers. Rather than being a point in Oracle's favor, I view this as tantamount to false advertising. But unfortunately, this false idea is pervasive among developers and DBA's alike.
I have worked extensively with Oracle, but since I started in SQL Server, I had a strong anti-cursor mindset pounded into me from the start (thank goodness). When I started working with Oracle and saw the extensive use of PL/SQL (which is all cursor-based as opposed to SQL) I questioned some of the developers and my fellow DBA's. At first I believed the line that "Oracle does fine with cursors." But after several months of familiarization, I decided to re-write some of the PL/SQL code to use JOINS instead of cursors etc... What I saw confirmed my suspicions. The same logic using SQL was many times faster than PL/SQL; in many cases it was an order of magnatude faster!
I couldn't believe that an entire department of developers and DBA's just swallowed such an unlikely line of BS. There is nothing magical about Oracle, it handles sets much more efficiently than row-at-a-time operations, just like SQL Server (and DB2 for that matter). Conversely, there is nothing "wrong" in SQL Server as compared with Oracle.
I'm not entirely sure what books you refer to. Certainly both the VP of Server technologies and the docs have suggested that one would naturally prefer set based methods to cursor solutions for at least 5 years eg http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:418619433157 . The same topic has frequently occurred on usenet with the same advice. If it is pervasive amongst the Oracle community there is little published evidence of this. False advertising is a strong claim, I suspect here it is over done.
What is true is
1) that the infinite loop that is described in the article could not occur in Oracle because of read consistency. This would be true even for an IOT.
2) avoiding sets for procedural code is a sure fire scalability and performance killer - its a shame that J2EE and .Net developers often don't get this.
Certainly the Sybex OCP Study Guides for 8i had no reference to the performance implications of cursors. I know, because I searched through them... I also grabbed every Oracle reference book owned by anyone in the entire department, most of which came from Oracle Press, and which included "tuning and diagnostic" books; while all of them dealt with HOW to code cursors, NONE of them so much as hinted that there were performance implications to doing so. Further, every one of the dozen or so developers and DBA's that I discussed the subject with, were under the "impression" that Oracle was somehow different, and thus immune from the performance problems that SQL Server labored under. I was assured time and again that I should quit barking up that tree. It wasn't until I devised several tests and proved my point that anyone would listen.
The problem, like you point out, is that those who are used to procedural (or OO) code are uncomfortable with set-based operations and they tend to see cursors as very familiar and "easy."
Granted, my experience is subjective and not in any way a comprehensive study of the subject, and I have run into Oracle DBA's and developers who know better. However, the vast majority of SQL Server DBA's/developers are aware of the drawbacks of using cursors because, among others, Microsoft is very up-front about their potential problems. At least a majority of people I have discussed the issue with (both SQL Server and Oracle folks) labor under the misconception that somehow Oracle "is optimized for cursors" or some such claptrap.
Don't misunderstand, I'm not bagging Oracle, I've worked with it for several years now and appreciate it's strengths, but I'm also not blind to its weaknesses...
No worries, I didn't think you were bagging Oracle. It was more a marketing thing for me. neither the sybex books - nor, more particularly, the Oracle Press books have anything to do with Oracle corp. The latter is a marketing agreement between Oracle and the publisher - the publisher, not Oracle, is responsible for the technical accuracy (or rather not) of the books.
<slight marketing bit>
Incidentally I did have the pleasure of tech reviewing Mark William's book on programming Oracle with .Net technologies (http://www.apress.com/book/bookDisplay.html?bID=378 . I think that the book was good - but 2-3 days to tech review whole chapters (which is apparently longer than the industry standard) makes it somewhat unsurprising that the quality of book is often very variable
Nice article. I'm glad the forum already beat me to asking the question about Oracle cursors.