[SQL] ADO에서 Cursor

연두비두밥·2024년 2월 14일

Cursor란?

cursor를 알기 전에 먼저 SQL(구조적 쿼리 언어)에 대한 특징을 알아야 한다. SQL Server는 해당 행이 SELECT, UPDATE, DELETE 문의 WHERE 절에 의해 정의된 집합의 멤버인 경우에만 해당 행에 대해 작업을 수행한다.
집합 지향 언어를 사용하면 각 행에 대해 별도의 명령을 실행하는 대신 그룹으로 모든 행에 변경 사항을 적용 할 수 있다.
(WHERE로 UUID와 같은 것을 불러와 한개만 볼 수 있지만, 이렇게 하나씩 보려면 한개당 하나의 쿼리문이 필요하게 된다.)

이런 집합 지향 언어의 문제점은 집합의 항목에 대한 순서 또는 개별성 개념이 부족하다는 것이다. 항목에는 하나의 속성. 즉, 집합의 구성원만 있다.
(=> 정리를 하면 WHERE로 조건에 맞는 항목들을 불러왔지만, 이 항목을 전체적으로 UPDATE, SELECT, DELETE를 할 뿐 부분적으로 선택해서 무엇인가를 할 수는 없다라는 말인 것 같다.)
따라서 집합의 첫 번째 행에서 마지막 행으로 이동할 수 없으며 특정 행을 대상으로 하는 다른 쿼리를 실행하지 않고는 특정 행에서 정보를 검색할 수도 없습니다.

Cursor는 이런 SQL SELECT문이 반환하는 행 집합의 행에 인위적으로 순서와 개별성을 부여하여 SQL의 이런 결함을 해결한다.

ADO가 커서를 사용하는 이유

응용 프로그램이 SQL Server에서 데이터 행을 검색할 때 정보를 처리하는 동안 행 집합을 저장할 장소가 필요하다. 커서는 메모리에 저장된 동적 배열과 유사하며, Recordest 개체는 해당 배열에 대한 인터페이스이다.
(=> 그러니깐, db에서 정보를 처리하는 동안 행 집합을 저장해야하고, 이를 위해 cursor를 사용하여 행 집합을 저장한다는 의미인가)

정리하면 테이블에서 여러 개의 행을 쿼리한 후에, 쿼리의 결과인 행 집합을 한 행씩 처리하기 위한 방식(+ 반복적인 배치작업 할 때도 이용)

ADO내에서 커서 기능

커서 위치는 커서가 열려 있는 동안 행 집합을 저장할 위치를 결정
커서 유형에 따라 커서 내의 움직임과 행 집합이 사용자의 변경 사항을 반영할지 여부 결정
커서의 잠금 유형은 사용자가 변경하려고 할 때 SQL Server가 서버의 행을 잠그는 방법을 지정

커서 위치

커서 위치에 따라 ADO 또는 SQL Server가 커서 관리하는지 여부가 결정된다.
SQL Server를 사용하면 서버측 커서가 TempDB 데이터 베이스의 공간을 차지간다. 전체 행 집합을 클라이언트로 보내는 대신 이를 TempDB에 저장한다. 그런 다음 데이터 베이스 드라이버는 클라이언트 애플리케이션의 요청에 따라 개별 행을 검색한다.

커서 유형

커서 유형	설명
앞으로 전용 커서	스크롤 불가능 커서라고도 불리며 일반적인 기본 커서 유형은 결과 집합을 통해 앞으로만 이동할 수 있다. 결과 세트를 앞뒤로 이동하는 스크롤을 지원하지 않는다. 결과 집합의 시작부터 끝까지 행 가져오기만 지원한다. 행 업데이트, 새 행 삽입, 행 삭제 가능(뒤로 이동만 불가능)
정적 커서	행을 추가하거나 삭제해도 행 목록이 변경되지 않음 또한 기존 레코드에 대한 변경 사항은 표시되지 않음 커서 소유자가 커서를 통해 변경한 내용은 즉시 표시되지만 정적 커서는 응용 프로그램이 커서를 새로 고칠 때까지 다른 사용자가 수정한 내용만 무시함. 예를 들어 정적 커서가 행을 가져오고 다른 애플리케이션이 해당 행을 업데이트한다고 가정하자. 응용 프로그램이 정적 커서에서 행을 다시 패치하는 경우 다른 응용 프로그램에서 변경한 내용에도 불구하고 표시되는 값은 변경되지 않음.
키셋 커서	키 세트 커서는 변경 사항을 감지하는 기능에서 정적 커서와 동적 커서 사이의 기능을 제공. 키 세트 커서를 사용하면 커서를 열 때 행 멤버십과 행 순서가 고정된다. 정적 커서와 마찬가지로 행 사이 앞뒤로 이동가능 하며, 결과 집합의 구성원 및 순서에 대한 변경 사항을 항상 감지하지는 않음. 동적 커서와 마찬가지로 결과 집합의 행 값에 대한 변경 사항을 감지함.
동적 커서	애플리케이션에서 누가 변경했는지에 관계없이 모든 변경 사항에 즉시 액세스해야 하는 경우 사용. 모든 사용자가 수행한 모든 삽입, 업데이트 및 삭제 문은 커서를 통해 볼 수 있다. 여러 사용자가 동시에 데이터 베이스에 행을 삽입, 업데이트 및 삭제하는 경우 동적 커서를 선택하라. 대신 절대 위치 지정을 지원하지 않음 예로 커서의 10번째 행을 식별할 수는 없다.

커서의 유형_MSDN

잠금 선택

잠금이란?

잠금은 DBMS가 다중 사용자 환경에서 행에 대한 액세스를 제한하는 프로세스이다. 행이나 열이 배타적으로 잠기면 잠금이 해제될 때까지 다른 사용자는 잠긴 데이터에 접근할 수 없다. 이렇게 하면 두 명의 사용자가 동시에 동일한 열을 연속으로 업데이트할 수 없다.
잠금은 리소스 관점에서 매우 비용이 많이 들 수 있기 때문에 데이터 무결성을 유지해야 하는 경우에만 사용해야한다.

What is Lock_MSDB

잠금 유형

잠금 유형	설명
adLockBatch 낙관적	일괄 업데이트 모드에 필요. 많은 애플리케이션은 한 번에 여러 행을 가져온 다음 삽입, 업데이트 또는 삭제할 젠체 행 집합을 포함하는 조정된 업데이트를 수행해야 한다. 일괄 커서를 사용하면 서버에 한 번만 왕복하면 되므로 업데이트 성능이 향상되고 네트워크 트래픽이 줄어든다.
adLock 낙관적	레코드를 편집하는 시점과 Update를 호출하는 시점 사이에 다른 사용자가 데이터를 변경할 수 있어 충돌이 발생할 가능성이 있습니다. 충돌 가능성이 낮거나 충돌을 쉽게 해결할 수 있는 상황에서는 이 잠금 유형을 사용합니다.
adLock 비관적	일반적으로 편집 직전에 데이터 원본에서 레코드를 잠그는 방식으로 레코드를 성공적으로 편집하는 데 필요한 작업을 수행합니다. 물론 이는 편집을 시작한 후 Update를 호출하여 잠금을 해제할 때까지 다른 사용자가 레코드를 사용할 수 없음을 의미 데이터를 동시에 변경할 수 없는 시스템에서는 이 유형의 잠금을 사용
adLockReadOnly	읽기 전용 레코드를 나타냅니다. 데이터를 변경할 수 없습니다. 읽기 전용 잠금은 서버가 레코드에 대한 잠금을 유지할 필요가 없기 때문에 가장빠른 유형의 잠금입니다.
adLock 지정되지 않음	잠금 유형을 지정하지 않습니다.

전반적으로 MSDN에 나와 있기도 하고, 찾아보면 나온다. 하지만 개념적으로는 이해가 가도 어떻게 사용하는지나 현재 프로젝트에 어떤식으로 적용되어 있는지 아직 잘모르겠다.
하지만 SQL의 단점을 보완하고 적절하게 행 데이터를 가공하기 위해 나왔다는 점만 인지한다면 이해 할 수 있을 것이다.