I'm learning about cursors for the first time because of a course assignment and it seems that the general consensus is that using cursors is very taxing on your server and generally not advised to use.
Barring legacy environments that use it, if you were to start a new project, would you use cursors?
For example in the C# camp, what benefit would using a cursor instead of a IQueryable<T> with Entity Framework bring? Are they worth the trouble?
1 Replies - 1463 Views - Last Post: 08 November 2010 - 07:19 PM
#1
Do people use database cursors in production anymore?
Posted 05 November 2010 - 05:56 AM
Replies To: Do people use database cursors in production anymore?
#2
Re: Do people use database cursors in production anymore?
Posted 08 November 2010 - 07:19 PM
This post probably would have received a lot more attention in the databases forum. As a general rule of thumb, using cursors in a solution to a database problem is always a last resort. Using cursors in sql and doing row-by-row computations is very slow, especially when working with large amounts of data. If I needed to do row-by-row computations on a set of records that would require me to use a cursor if I were to do it in SQL, then I would most likely do it at the application level using .NET (or something similar) instead.
On the other hand. Pulling the data into the application layer and doing row-by-row processing all of the time when a perfectly efficient set based solution at the database layer can be used, is also a bad thing. You could be degrading your applications performance that way as well...
On the other hand. Pulling the data into the application layer and doing row-by-row processing all of the time when a perfectly efficient set based solution at the database layer can be used, is also a bad thing. You could be degrading your applications performance that way as well...
Page 1 of 1
|
|

New Topic/Question
Reply


MultiQuote




|