April 15, 2002 at 2:44 pm
Hello, fellow programmers!
Recently I've learned that "cursors are very bad for you" and the best way to program 'cursor like' procedures - to use Temporary tables. Then another one came - "try to avoid temp.tables".
Now I'm a little bit confused: what Is good for you?
Any suggestions, opinions will be appreciated!
April 16, 2002 at 1:56 am
OK let's get this in perspective (sorry I'm going on my soapbox). First up SQLServer is most efficient at Set-Wise operations, soo if you can process your data using straightforward. SQl Updates, Selects, Inserts etc. do so.
The key word here is STRAIGHTFORWARD. The more lines there are in you SQL, the more complex it is, the harder it is to support.
If your app' needs to minutely evaluate the contents of each row in a set so as to be able to decide how to manipulate the data then stepping through a Cursor is often the easiest and most supportable way of doing just that. easier to see what's going on, easier to change and enhance than a convoluted single SQL statment.
HOWEVER I use this technique with FAST FORWARD Cursors ONLY, trying to work with adynamic updateable Cursor is, in my opinion, a recipe for stress and grief.
as developers it is up to us to choose the most apt tool to do a job. I think it was Plato who said that "It is only in excess that a practice becomes destructive. Practice all things in moderation."
Phew I'm a much better person for that.
I have found it is possible to please all of the people all of the time if you do exactly what they want. Harold Macmillan 1961
April 16, 2002 at 9:55 am
In Oracle there is always a cursor created and referred to for operations. Something I did not know until recently and it seems lots of people coming to SQL Server from Oracle think this is how you should implement solutions in SQL Server.
In general, you should avoid cursors in SQL Server because it is a less efficient method of working with data IN SQL SERVER. Set based operations that use subqueries or well structured joins are usually more efficient in SQL Server. However, there are times when you do need row by row processing and a cursor might be a better solution than running multiple queries over and over.
You have to look at both solutions and see what works better. You might also make a decision that speeds development, but forces you to rewrite later on. Not always a bad choice either.
I tend to agree with crosspatch above.
Steve Jones
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply