One such time would be when you want to write a script to restore a bunch of databases from backup files on a disk. However, other than for backwards compatibility they can still serve us well in the right situations. COBOL, FORTRAN, old style C etc.) So in that regard they are just plain old-fashioned. SQL Server cursors and any other type of cursors date back to before procedural programming languages could handle sets of data and required to be split into rows (E.g. Take this simple SELECT statement as an example: This is because SQL Server, like any good relational database management system (RDBMS), is optimized for set-based operations. The reason for this is plain and simple they are the best way to slow down an application. In any good development environment people will talk about cursors as if they were demons to be avoided at all costs. SQL Server cursors are notoriously bad for performance. Yes, there are times when cursors are OK to use and they can be tuned slightly by playing with their different types but, as a general rule of thumb, one should try to avoid them at all costs. It is for this reason that we so often find SQL Server cursors written into the business logic of an application and it is a real pity because they are real performance hogs. This is because they break free of the shackles of set-based logic that is the normal when writing most T-SQL scripts. People that do not have the background in Database Administration or who did not enjoy database classes while studying will often find SQL Server cursors handy and fun to write. We explained that a cursor is a row-based operation that takes a given SELECT statement and breaks downs the processing of the data into looping executions. In a previous article we discussed the how to set up a basic cursor.
0 kommentar(er)
