사람들이 왜 SQL 커서를 너무 싫어합니까? [닫은]

오버 헤드와 불편으로 인해 커서를 사용하지 않으려는 것을 이해할 수는 있지만 사람들이 커서를 사용하지 않기 위해 많은 시간을 할애하는 심각한 커서 공포증이있는 것처럼 보입니다.

예를 들어, 한 질문은 커서로 명백히 사소한 작업을 수행하는 방법을 물었고 재귀 사용자 정의 함수가있는 공통 테이블 표현식 (CTE) 재귀 쿼리를 사용하여 제안 된 대답은 32로 처리 할 수있는 행 수를 제한하지만 (SQL 서버의 재귀 함수 호출 제한으로 인해). 이것은 단순한 커서 사용을 피하기 위해 엄청난 노력을 기울이지 말고 시스템 수명을위한 끔찍한 해결책으로 저를 놀라게합니다.

이 미친 증오의 이유는 무엇입니까? 일부 '공인 기관'은 커서에 대해 fatwa를 발행 했습니까? 말로 표현할 수없는 악이 커서의 중심에 숨어 어린이의 도덕이나 다른 것들의 도덕을 손상 시키는가?

Wiki 질문, 담당자보다 답변에 더 관심이 있습니다.

관련 정보 :

SQL Server 빨리 감기 커서

편집 : 더 정확하게하자 : 나는 일반적인 관계 연산 대신 커서를 사용해서는 안된다는 것을 이해합니다 . 그것은 쉬운 일이 아닙니다. 내가 이해하지 못하는 것은 사람들이 커서가 더 간단하고 효율적인 솔루션 일 때조차도 쿠 티나 무언가를 가진 것처럼 커서를 피하기 위해 길을 가고 있다는 것입니다. 명백한 기술적 효율성이 아니라 나를 괴롭히는 것은 비이성적 인 증오입니다.

커서가있는 "오버 헤드"는 API의 일부일뿐입니다. 커서는 RDBMS의 일부가 후드에서 작동하는 방식입니다. 자주 CREATE TABLE와 INSERT이 SELECT문을, 그리고 구현은 분명 내부 커서 구현입니다.

더 높은 수준의 "세트 기반 연산자"를 사용하면 커서 결과가 단일 결과 세트로 묶이므로 API가 줄어 듭니다.

커서는 일류 컬렉션을 제공하는 최신 언어보다 우선합니다. 구 C, COBOL, Fortran 등은 널리 사용될 수있는 "컬렉션"개념이 없기 때문에 한 번에 하나씩 행을 처리해야했습니다. Java, C #, Python 등에는 결과 세트를 포함하는 일류 목록 구조가 있습니다.

느린 문제

일부 서클에서 관계형 조인은 미스터리이며 사람들은 간단한 조인 대신 중첩 커서를 씁니다. 나는 많은 서사시로 작성된 서사시 중첩 루프 연산을 보았습니다. RDBMS 최적화 방지 그리고 정말로 천천히 달리기.

중첩 된 커서 루프를 조인으로 대체하기 위해 간단한 SQL을 다시 작성하며 단일의 평평한 커서 루프는 프로그램을 100 번째로 실행할 수 있습니다. [그들은 내가 최적화의 신이라고 생각했습니다. 내가 한 것은 중첩 루프를 조인으로 바꾸는 것입니다. 여전히 커서를 사용했습니다.]

이 혼란은 종종 커서의 기소로 이어집니다. 그러나 이것은 커서가 아니며 문제가되는 커서의 오용입니다.

크기 문제

서사시 결과 집합 (예 : 테이블을 파일로 덤프)의 경우 커서가 필수적입니다. 집합 기반 작업은 실제로 큰 결과 집합을 메모리의 단일 컬렉션으로 구체화 할 수 없습니다.

대안

ORM 레이어를 가능한 많이 사용하려고합니다. 그러나 그것은 두 가지 목적이 있습니다. 먼저, 커서는 ORM 구성 요소에 의해 관리됩니다. 둘째, SQL이 응용 프로그램에서 구성 파일로 분리됩니다. 커서가 나쁘지는 않습니다. 모든 열기, 닫기 및 가져 오기를 코딩하는 것은 부가 가치 프로그래밍이 아닙니다.

커서는 사람들이 세트 기반 환경에 절차 적 사고 방식을 과도하게 적용하도록합니다.

그리고 그들은 느리다 !

에서 SQLTeam :

커서는 SQL Server 내부의 데이터에 액세스하는 가장 느린 방법입니다. 한 번에 한 행에 액세스해야하는 경우에만 사용해야합니다. 내가 생각할 수있는 유일한 이유는 각 행에서 저장 프로 시저를 호출하는 것입니다. 에서 커서 성능 기사 나는 커서가있는 것을 발견 이상 서른 배 느린 세트를 기반으로 대안보다 .

위의 답변은 "커서가 SQL Server 내부의 데이터에 액세스하는 가장 느린 방법입니다 ... 커서가 설정된 기반의 대안보다 30 배 이상 느립니다."

이 진술은 많은 상황에서 사실 일 수 있지만, 포괄적 인 진술로서 문제가 있습니다. 예를 들어, 지속적인 프로덕션 읽기를받는 큰 테이블의 많은 행에 영향을주는 업데이트 또는 삭제 작업을 수행하려는 경우 커서를 잘 활용했습니다. 한 번에 한 행씩 이러한 업데이트를 수행하는 저장 프로 시저를 실행하면 세트 기반 작업이 읽기 작업과 충돌하여 끔찍한 잠금 문제가 발생하여 프로덕션 시스템이 완전히 종료 될 수 있기 때문에 세트 기반 작업보다 빠릅니다. 극단적 인 경우).

다른 데이터베이스 활동이 없으면 세트 기반 조작이 보편적으로 더 빠릅니다. 프로덕션 시스템에서는 다릅니다.

커서는 집합 기반 작업이 더 나은 곳에서 SQL 개발자를 시작하여 사용하는 경향이 있습니다. 특히 사람들이 전통적인 프로그래밍 언어를 배우고 나서 SQL을 배우면 "이러한 레코드를 반복하는"사고 방식은 사람들이 커서를 부적절하게 사용하게하는 경향이 있습니다.

가장 심각한 SQL 서적에는 커서 사용에 관한 장이 포함되어 있습니다. 잘 작성된 커서는 커서가 그 자리에 있지만 세트 기반 조작에는 사용해서는 안된다는 것을 분명히합니다.

커서가 올바른 선택이거나 적어도 올바른 선택 인 상황이 분명히 있습니다.

옵티마이 저는 종종 커서 대}을 사용할 때 관계 대수를 사용하여 문제점을 변환 할 수 없습니다. 커서는 종종 문제를 해결하는 좋은 방법이지만 SQL은 선언적 언어이며, 제약 조건에서 통계 및 색인에 이르기까지 데이터베이스에 많은 정보가 있습니다. 이는 옵티마이 저가 커서가 솔루션을 거의 명시 적으로 지시합니다.

Oracle PL / SQL 커서에서는 테이블 잠금이 발생하지 않으며 대량 수집 / 벌크 페칭을 사용할 수 있습니다.

Oracle 10에서 자주 사용되는 암시 적 커서

  for x in (select ....) loop
    --do something 
  end loop;

한 번에 100 개의 행을 가져옵니다. 명시 적 대량 수집 / 대량 반입도 가능합니다.

그러나 PL / SQL 커서는 최후의 수단으로, 세트 기반 SQL의 문제점을 해결할 수 없을 때 사용하십시오.

또 다른 이유는 병렬화인데, 데이터베이스가 행 단위 명령 코드보다 큰 세트 기반 명령문을 병렬화하는 것이 더 쉽습니다. 함수형 프로그래밍이 점점 더 대중화되는 이유 (Haskell, F #, Lisp, C # LINQ, MapReduce ...)와 같은 이유로 함수형 프로그래밍으로 병렬화가 더 쉬워집니다. 컴퓨터 당 CPU 수가 증가함에 따라 병렬화가 점점 더 문제가되고 있습니다.

일반적으로 관계형 데이터베이스에서는 커서를 사용한 코드 성능이 세트 기반 작업보다 훨씬 나쁩니다.

위의 답변은 잠금의 중요성을 충분히 강조하지 못했습니다. 나는 종종 테이블 레벨 잠금을 초래하기 때문에 커서를 좋아하지 않습니다.

그만한 가치가 있기 때문에 커서가 세트 기반 대응을 수행하는 "한 곳"이 누계에 있다는 것을 읽었습니다. 작은 테이블에서 열을 기준으로 행을 합산하는 속도는 세트 기반 연산을 선호하지만 테이블의 행 크기가 증가함에 따라 커서는 실행 총계 값을 다음 패스로 전달할 수 있기 때문에 커서가 더 빨라집니다. 고리. 이제 누계를 수행 해야하는 곳 은 다른 주장입니다 ...

이 페이지의 기사에 동의합니다 :

http://weblogs.sqlteam.com/jeffs/archive/2008/06/05/sql-server-cursor-removal.aspx

성능 (비) 문제 이외의 커서의 가장 큰 실패는 디버깅하기가 어렵다는 것입니다. 특히 디버깅이 비교적 쉽고 언어 기능이 훨씬 쉬운 대부분의 클라이언트 응용 프로그램의 코드와 비교할 때 특히 그렇습니다. 사실, 커서로 SQL에서 수행하는 거의 모든 작업이 클라이언트 응용 프로그램에서 먼저 발생해야한다고 주장합니다.

해당 커서 예제를 게시하거나 질문에 링크 할 수 있습니까? 재귀 CTE보다 더 나은 방법이있을 것입니다.

다른 주석 외에도 커서를 잘못 사용하면 (종종) 불필요한 페이지 / 행 잠금이 발생합니다.

사람들이 당신과 다른 견해를 가지고 있기 때문에 단순히 사람들을 "미치 광"이라고 부르지 않고 그들이하는 방식을 느끼는 데 충분한 이유가있는 전문가를 조롱하려고하기 때문에 아마도 두 번째 단락 이후에 당신의 질문을 결론 지었을 것입니다.

귀하의 질문에 관해서는, 커서가 필요할 수있는 상황이 있지만, 필자의 경험에 따르면 개발자는 커서가 실제 경우보다 더 자주 FAR을 사용해야한다고 결정합니다. 커서를 너무 많이 사용하여 커서를 잘못 사용하는 것과 비교할 때 커서를 사용하지 않을 가능성은 제 의견으로는 훨씬 높습니다.

basicaly 동일한 작업을 수행하는 2 개의 코드 블록. 어쩌면 조금 이상한 예이지만 요점을 증명합니다. SQL Server 2005 :

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

단일 업데이트는 156ms가 걸리고 커서는 2016ms가 걸립니다.