|
|
Posted by Doug on 03/01/06 03:31
Hello,
I would agree that you do not need cursors in 99 percent of the cases.
In fact, as an example, I bet for most apps there are at least 300
selects for every cursor.
But sometimes you just can't get around it. Sometimes the business
logic just forces you to examine each "record" once, and do weird logic
on it. And sometimes, the logic is such that one result can change the
way you process the rest.
I had an app once that took money, and split it into diffferent
buckets. The calculations were very complex, and the rules were
actually stored in tables. As an example, sometimes there were
percentages, sometimes hard amounts, and the number of buckets you
dumped the money into changed radically. Further, you had to look in a
table to figure out whether to charge sales tax on the whole thing,
parts of it, or none of it.
I dumped all this into a stored procedure, and used a cursor to load
teh rules for splitting the money.
It was not going to work on set based logic. And, I really didn't want
the rules and calculations completed on the client level. And if
something went REALLY wrong, I wanted to back the whole thing out.
For this, SQL server, stored procedures, and cursors were really cool.
It can be "proven" using a mathematic proof that cursors ARE required
in certain circumstances. Like we both said, cursors are by far the
exception, adn like you said, cursors are very often implemented too
frequently.
regards,
doug
Navigation:
[Reply to this message]
|