|
|
Posted by Stu on 03/02/06 17:19
Sorry to butt in, but I think the answer to the question of "to curse,
or not to curse" (what else would you call stepping through a cursor?)
lies in David's statement of what the "average SQL programmer" does.
Some of us are outliers.
I think that if you do a lot of integration work where you're
retriveing data from databases where you have little control over the
design (ie, third-party applications, legacy databases, etc) then
you'll find yourself using more of the specialty tools of SQL Server
than standard SQL. If you're working in data warehousing where data
denormalization is a standard practice, then flattening your data
during the import process using a cursor may be a viable option (and
possibly your only viable option).
However, I do agree that 99% of the time for MOST developers, cursors
are not the optimal choice, and if you work with them a lot, it's a
struggle to think in set-based terms. In my shop, we alternate between
OLAP and OLTP a lot, and I have to mentally switch gears to keep from
applying procedural logic to my relational designs and relational logic
to my procedural operations.
To answer the OP, I think David is correct; ignore cursors for now.
Learn how to design and think in sets, and save row-based operations
until much later in your career.
Stu
Navigation:
[Reply to this message]
|