MFC DAO 및 MFC ODBC 클래스

융통성이 증가된 DAO

1995 년 10 월 MFC DAO(Data Access Objects) 데이터베이스 클래스가 릴리스된 이후 MFC 데이터베이스 개발자들은 어떤 클래스 집합을 사용할지 선택에 어려움을 겪었습니다. 여기에서는 이러한

문제를 주로 다루지는 않습니다. 대신 개발자가 각 상황에 가장 적합한 MFC 데이터베이스 클래스를

결정할 수 있는 옵션을 중점적으로 다룹니다.

대부분의 MFC 개발자는 약 3 년 6 개월 이상 ODBC(Open Database Connectivity) 데이터베이스

클래스를 사용해 왔으므로 이 클래스에 익숙합니다. 이 클래스들은 MFC 4.2 에서 몇 가지 중요한 개선이

이루어졌습니다.

C++ 개발자의 경우 그 동안 Microsoft Access 및 Visual Basic 프로그래밍 시스템만 사용할 수

있었으므로 DAO 에 익숙하지 않을 수도 있습니다. 여러분이 DAO 에 익숙하다면 MFC 로 DAO 를

구현하는 것은 어렵지만 여전히 광범위하게 사용되고 있다는 사실을 알 필요가 있습니다.

MFC ODBC 클래스에 익숙한 개발자의 경우 MFC DAO 클래스가 ODBC 클래스보다 다양한 기능을

가지고 있지만 DAO 클래스가 ODBC 클래스를 대체할 수는 없다는 점을 알 필요가 있습니다.

MFC 데이터베이스 전략

MFC 에 익숙하지 않은 사람들의 경우 MFC 가 데이터베이스 클래스를 보급하는 설계 철학을 가지고

있다는 점을 상기할 필요가 있습니다.

MFC 는 Windows 운영 체제 API 를 씬 래퍼(Thin Wrapper)로 캡슐화하여 추상화에 필요한 C++ 기능을 제공합니다. 필요하면 기본 API 에 값을 추가합니다. 그러나 MFC 는 대부분 직접 실행되지

않습니다.

MFC 가 복잡한 API 를 캡슐화하는 것처럼 데이터베이스 클래스는 난해한 기술들을 캡슐화합니다. MFC 는

Intel, Unix 및 Alpha 로 이식할 수 있기 때문에 데이터베이스 응용 프로그램 솔루션을 이식할 수

있습니다.

Microsoft Access 및 Visual Basic 과 동일한 레코드 집합 모델을 사용하므로 이미 이 제품들을 사용하고

있는 개발자는 새 패러다임을 배울 필요가 없습니다. 또한 두 클래스 집합의 아키텍처가 근본적으로 같기

때문에 한 클래스 집합을 사용하는 개발자는 쉽게 다른 클래스 집합으로 전환하여 사용할 수 있습니다.

MFC 데이터베이스 클래스

ODBC 데이터베이스 클래스는 MFC 버전 1.5 이상에서 사용할 수 있습니다. Visual C++ 버전 2.0 은

동일한 클래스의 32 비트 버전을 제공합니다. 이 클래스들은 널리 사용되고 있으며 업계 표준으로

인정되고 있습니다. 또한 ODBC 의 호환성, 즉 다양한 ODBC 데이터 원본을 가진 클래스를 사용하여

생성된 응용 프로그램을 사용할 수 있는 기능 때문에 다른 데이터베이스 개발 옵션에서 선호되고 있습니다. 최근의 개선된 성능으로 인해 ODBC 데이터베이스 클래스는 더욱 매력적인 옵션이 되었습니다.

MFC 4.0 의 DAO 데이터베이스 클래스는 대부분의 경우에 ODBC 를 사용하지 않고 직접 데스크톱 데이터

원본을 액세스할 수 있습니다. DAO 데이터베이스 클래스는 한 번에 2 가지 이상의 데이터베이스 형식을

열고 다양한 데이터 원본을 사용할 수 있는 기능과 데이터 정의 언어(Data Definition Language) 기능을

통해 중요한 개발 옵션으로 부상하였습니다.

이제 어떤 데이터베이스 클래스 집합을 사용해야 하는지 질문할 준비가 되었습니다. 이 질문에 대한 대답은

여러분의 프로젝트와 관련된 다양한 정보가 없으면 결정하기 어렵습니다. 그러나 가장 우선적으로 고려할

사항은 사용하고 있는 데이터 원본의 종류입니다. 데스크톱 데이터를 주로 사용하는 경우 효율적이고

강력한 MFC DAO 데이터베이스 클래스를 사용할 것을 권합니다. ODBC 서버 기반 데이터를 주로

사용하는 경우 ODBC 기반 클래스를 사용하면 프로젝트를 더 효율적으로 만들 수 있습니다.

기타 고려할 사항으로는 네트워크의 종류, 확장 요구사항, 그리고 무엇보다도 속도가 중요합니다. 가장

우선적으로 해야 할 작업은 최선의 데이터베이스 클래스 집합을 사용하여 응용 프로그램의 프로토타입을

구축하는 것입니다. 벤치마킹을 통해 최고의 성능을 나타내는 옵션을 판별할 수 있습니다.

결정은 전적으로 여러분에게 달려 있습니다.

연속적인 선택

데이터베이스 응용 프로그램을 생성하기 위해 선택할 수 있는 집합은 광범위합니다. 데스크톱

데이터베이스 응용 프로그램은 물론 견고한 클라이언트/서버 데이터베이스 응용 프로그램에도 사용할 수

있습니다. 확실한 2 가지 선택은 Microsoft Access 97 .MDB 데이터에서 MFC DAO 데이터베이스

클래스를 사용하는 것과 Microsoft SQL Server 6.5 에서 MFC ODBC 데이터베이스 클래스를 사용하는

것입니다. 이 두 쌍은 서로 효율적으로 동작할 수 있도록 설계되었습니다. 그러나 이러한 선택은 대개 이미

알고 있을 것입니다. 그 밖에 달리 선택할 수 있는 방법은?

다음은 여러분이 결정할 수 있는 간단한 과정입니다.

데이터 원본 요구 판별

얼마나 큰 데이터베이스가 필요합니까? 데이터를 얻기 위해 2명 이상이 필요합니까? 선택한 데이터

원본을 통해 이 과정의 나머지 부분이 결정되는 경우도 있습니다.

인터페이스 요구 판별

사용자 입력이 많은 인터페이스(예를 들어, 사용자가 자신의 쿼리를 설계할 수 있는 인터페이스)가 필요한

경우 데이터베이스를 신중하게 조정하고 분산해야 합니다. 예를 들어, 자주 변경할 필요가 없는 데이터를

가진 목록 상자가 필요하고 서버 기반 데이터 원본을 선택한 경우 대개 변경되지 않는 데이터는 서버 대신

로컬에 저장하는 것이 합리적입니다.

연결 요구 판별

현재 수 많은 네트워크 프로토콜이 사용되고 있습니다. 여기에서는 네트워크에 대해 설명하지 않지만

네트워크의 데이터 오류를 피할 수 있도록 데이터베이스 응용 프로그램을 최적화하는 방법을 알 필요가

있습니다.

알맞은 도구 선택

Microsoft 는 데이터베이스 개발자(Microsoft Access, Visual Basic, Visual Basic Enterprise, Visual C++/MFC 및 SQL Server)를 위한 다양한 옵션을 가지고 있으며 일부 중복되는 기능도 있습니다. 여기에서는 Visual C++/MFC 옵션을 중점적으로 설명하지만 다른 옵션들도 고려해야 합니다.

구현 전에 프로토타입 작성

이 내용은 중요하기 때문에 여기에서 여러 차례 언급했습니다. 물론 잘 선택했겠지만 솔루션이 실제로

동작하지 않으면 끝난 것이 아닙니다!

다시 말하지만 여기에서는 여러분이 MFC 의 데이터베이스 클래스에 대해 배우기를 원한다고 가정하고

진행합니다. 첫 프로토타입 작성 방향을 올바로 설정할 수 있도록 가능한 한 많은 옵션을 조사하겠습니다.

MFC ODBC 데이터베이스 클래스는 Microsoft Access 및 Visual Basic 의 레코드 집합 모델을

사용합니다. 클래스에 내장된 구성원 함수를 사용하여 레코드 집합을 필터, 정렬, 스크롤하거나 기타

방법으로 조작할 수 있습니다. 기본 ODBC 드라이버는 특정 응용 프로그램의 기능에 영향을 줍니다. 따라서 이식성을 높이기 위해서는 응용 프로그램을 더 일반적으로 작성하거나 저수준 ODBC 기능을

사용해야 합니다. 필요한 경우 ODBC 를 직접 호출하여 특정 작업을 수행할 수 있습니다. 이제 이 집합에서

개별 클래스를 조사합시다.

MFC 의 ODBC 데이터베이스 클래스

MFC 를 사용하면 필요할 때마다 기본 API(이 경우에는 ODBC)를 호출할 수 있습니다.

CDatabase 개체는 데이터 원본과의 연결을 나타내며 이 연결을 통해 데이터 원본을 조작할 수

있습니다. 데이터 원본은 일부 데이터베이스 관리 시스템(DBMS)에 의해 호스트되는 데이터의 특정

인스턴스입니다. DBMS 의 예로는 Microsoft SQL Server, Microsoft Access, Borland dBASE 및

xBASE 가 있습니다. 응용 프로그램에서 한 번에 하나 이상의 CDatabase 개체를 활성화할 수 있고

하나의 데이터베이스 개체에 대해 여러 개의 연결을 가질 수 있습니다.

CRecordset 개체는 데이터 원본에서 선택한 레코드 집합을 나타냅니다. CRecordset 개체는 "레코드

집합"으로 알려져 있으며 다음과 같이 3 가지 형태 즉, 다이너셋, 스냅샷 및 동적 레코드 집합으로

사용됩니다. 다이너셋은 다른 사용자가 업데이트할 때 동기화를 유지하는 레코드 집합입니다. 스냅샷은

스냅샷 시에 데이터베이스의 상태를 반영하는 정적 레코드 집합입니다. 동적 레코드 집합은 다이너셋과

유사하며 일반적으로 Microsoft SQL Server 에서만 사용됩니다. 각 형태는 레코드 집합이 열려 있을 때

고정된 레코드 집합을 나타내지만 다이너셋이나 동적 레코드 집합의 레코드를 스크롤할 때 다른 사용자나

응용 프로그램의 다른 레코드 집합에 의해 변경된 내용이 순차적으로 적용됩니다.

MFC 4.2 에서는 CRecordset 클래스에 책갈피 형태의 새로운 탐색 기능 및 레코드의

AbsolutePosition 을 식별하고 탐색할 수 있는 기능이 추가되었습니다. 책갈피는 해당 식별자를

호출하여 특정 레코드로 복귀하는 데 사용할 수 있는 고유 식별자입니다.

CRecordView 클래스는 데이터를 표시하기 위한 MFC 의 폼입니다. CRecordView 는 CFormView

를 기반으로 하기 때문에 이 클래스의 모든 기능을 상속 받습니다. 기본적으로 폼 보기는 대화 상자

템플릿을 창의 클라이언트 영역으로 확장합니다. 따라서 쉽게 컨트롤을 추가하고 필드 데이터를 표시할 수

있습니다.

AppWizard 및 ClassWizard 를 사용하여 ODBC 기반 데이터베이스 응용 프로그램을 생성하면 레코드

집합의 열이 자동으로 구성원 변수에 정적으로 바인드되므로 대화 상자 템플릿에 추가할 수 있습니다.

CDBException 개체는 데이터베이스 클래스에서 발생하는 예외 조건을 나타냅니다. 이 클래스는 예외의

원인을 판별하거나 예외를 설명하는 텍스트 메시지를 표시하는 데 사용할 수 있는 2 개의 공용 데이터

구성원을 포함하고 있습니다. CDBException 개체는 데이터베이스 클래스의 구성원 함수에 의해

생성되고 발생됩니다.

CFieldExchange 클래스는 데이터베이스 클래스에 의해 사용되는 RFX(Record Field Exchange) 루틴을 지원합니다. 이 클래스는 사용자 정의 데이터 형식의 데이터 교환 루틴을 작성할 경우에 사용하며

그 밖의 경우에는 이 클래스를 직접 사용하지 않습니다. RFX 는 레코드 집합 개체의 필드 데이터 구성원과

데이터 원본에서 현재 레코드의 대응되는 필드 사이에 데이터를 교환합니다. RFX 는 데이터 원본의 양방향

모두에서 교환을 관리합니다.

DAO(Data Access Objects)

DAO 는 기본적으로 21 개의 개체와 20 개의 컬렉션으로 구성되어 있습니다. DAO 는 테이블 및 필드와

같은 개별 개체와 이 개체들이 속한 컬렉션을 추가로 제공합니다. 이와 같이 명확한 개체의 계층 구조를

통해 데이터베이스를 개발할 때 개체 지향 원칙을 쉽게 적용할 수 있습니다.

DAO 는 지속적으로 개선되어 왔습니다. Microsoft Access 버전 1.0 에서 나타난 DAO 버전 1.0 은

테이블과 쿼리 구조에 대한 인터페이스 및 제한된 속성을 가진 테이블, 다이너셋, 스냅샷만 제공합니다. Visual Basic 버전 3.0 의 DAO 1.0 에서는 구조를 체계적으로 표시하기 위해 TableDef, QueryDef 및

Field 개체를 추가하였습니다.

Microsoft Access 버전 2.0 의 DAO 버전 2.0 에서는 거의 모든 Microsoft Jet 기능에 대해 프로그램

액세스가 가능한 OLE 자동화가 처음 소개되었습니다. DAO 버전 2.0 은 견고한 개체 및 속성 집합과 함께

완전한 개체 모델을 가지고 있습니다.

DAO 버전 2.5 는 16 비트 플랫폼에서 ODBC Desktop Database Drivers 버전 2.0 과 함께 사용할 수

있도록 작성된 ODBC Desktop Database Driver 들로 구성되어 있습니다. 16 비트 버전은 Visual Basic 4.0 16 비트 버전에서 소개되었습니다.

DAO 버전 3.0 은 Microsoft Access for Windows 95, Visual Basic 버전 4.0(32 비트), Microsoft Excel 버전 7.0 및 Visual C ++ 버전 4.0 에서 소개되었습니다. DAO 는 모든 호환 호스트에 대해

독립적인 인터페이스를 지원하도록 개선되었습니다.

DAO 버전 3.5 는 Microsoft Access for Windows 97 에서 소개되었으며 새로운 ODBCDirect COM 개체를 포함하고 있습니다. MFC DAO 데이터베이스 클래스는 이 개체에 대한 클래스를 포함하고 있지

않습니다.

특히 DAO 인터페이스는 OLE COM 을 기반으로 하고 있기 때문에 미래의 기술과 운영 체제에 적절히

부응할 수 있습니다.

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

다음은 DAO 계층 구조를 나타내는 도표입니다. 가장 위에 DBEngine 개체가 있고 다른 모든 개체들을

포함하고 있습니다. 이 개체는 하나의 엔진만 가질 수 있기 때문에 컬렉션이 없는 유일한 개체입니다. 나머지 개체들이 자신이 속한 컬렉션을 갖는 이유는 여러 개의 작업 영역 및 데이터베이스 등을 가질 수

있도록 하기 위해서 입니다.

작업 영역에서 기본 테이블(.MDB)이나 추가/연결 테이블과 같은 하나 이상의 데이터베이스를 가질 수

있습니다. 각 데이터베이스에는 하나 이상의 테이블, 쿼리 및 레코드 집합이 있으며 이들은 각각 필드와

인덱스 및 다른 형식의 개체를 가지고 있습니다.

또한 DAO 의 보안 모델을 구성하는 User 및 Group 개체가 작업 영역에 연결되어 있습니다.

Errors 개체는 홀로 떨어져 엔진 개체와 연결되어 있습니다.

Errors 컬렉션의 개체들은 다른 DAO 컬렉션과 상이한 방식으로 추가됩니다. 가장 세부적인 오류가

컬렉션의 끝에 나오고 가장 일반적인 오류가 처음에 나옵니다.

MFC 및 DAO

이제 MFC 로 DAO 를 구현하는 방법에 대해 알아봅시다. 각 DAO 개체를 개별적으로 래핑하지 않기

때문에 MFC 는 기본적으로 DAO 계층 구조를 단순하게 만듭니다. 21 개가 아닌 8 개의 개체가 제공됩니다.

모든 DAO 기능을 Security 개체의 예외, 즉 User, Group 및 새 ODBCDirect 개체와 함께 캡슐화합니다. 우리는 신중하게 이 작업을 했습니다. 예를 들어, 보안 개체의 경우 클래스를 생성해도 DAO 를 사용하는

것과 별다른 차이가 없기 때문에 DAO 를 직접 호출하여 이 개체들을 처리합니다. MFC 는 다음과 같은

원칙을 가지고 있습니다. 즉, 부가가치가 있는 경우에 클래스를 생성합니다. 그러나 여기에서는 MFC Technical Note 54 에서 보안 모델을 구현하는 방법에 대한 지침을 제공합니다.

또한 컬렉션에 개체를 추가하기 위한 DAO 요구사항을 관리합니다. DAO 에서 개체를 생성한 다음

컬렉션에 추가합니다. 예외적으로 이 작업을 자동으로 수행합니다. 이 경우에 개발자가 개체를 별도

단계로 추가(Append)할 수 있어야 합니다.

ODBC 데이터베이스 클래스에서는 동적 바인딩이 가능하지만 MFC 클래스에는 이 기능이 내장되어 있지

않습니다. 대신 DAO 데이터베이스 클래스가 내장되어 있으므로 훨씬 쉽게 동적 바인딩을 구현할 수

있습니다. 두 번째 데모에서는 여기에 대해 설명합니다.

DAO 는 데이터베이스, 테이블, 레코드 집합 등을 생성할 수 있는 SQL 로부터 DDL 을 제공합니다. DDL 은

ODBC 클래스에서 사용할 수 없습니다.

마지막으로 필요에 따라 기본 DAO OLE 개체를 언제든지 호출할 수 있습니다.

MFC DAO 데이터베이스 클래스 계층 구조

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

CObject 에서 파생된 5 개의 MFC DAO 클래스(CDaoWorkspace, CDaoDatabase, CDaoTableDef, CDaoQueryDef, CDaoRecordset)는 모두 상위 클래스의 기능을 가지고

있습니다.

CDaoException 는 CException 에서 파생되었으며 기본 DAO Errors 개체로부터 오류 메시지를

표시하는 기능을 포함한 해당 클래스의 특징을 가지고 있습니다.

CDaoRecordView 는 위에서도 언급했지만 CFormView 에서 파생되었으며, 또한 CFormView 는

CScrollView 에서 파생되었습니다. CDaoRecordView 클래스는 폼 기반 데이터를 신속하게 표시하고

구현하기 쉬운 장점을 가지고 있습니다. 또한 CDaoRecordView 를 지원하는 마법사가 있습니다. 이

클래스의 기능은 실제로 CRecordView 클래스와 동일합니다.

CDaoFieldExchange 클래스는 DAO 데이터베이스 클래스에 의해 사용되는 DFX(DAO Record Field Exchange) 루틴을 지원합니다. 사용자 정의 DFX 루틴을 생성할 경우 이 개체를 직접 호출해야 합니다.

MFC DAO 데이터베이스 클래스

CDaoWorkspace 는 DBEngine 개체와 Workspace 개체를 모두 캡슐화합니다. MFC DAO 클래스가

작업 영역을 제공한다는 사실은 매우 중요합니다. ODBC 데이터베이스 클래스는 한 번에 2 개 이상의

데이터베이스 연결을 지원하지 않습니다.

트랜잭션은 ODBC 클래스의 레코드 집합 수준 대신 DAO 데이터베이스 클래스의 작업 영역 수준에서

수행됩니다. 한 트랜잭션이 모든 열린 데이터베이스와 레코드 집합에 영향을 미치거나 특정

데이터베이스에만 영향을 미치도록 할 수 있습니다.

대부분의 경우 Workspace 개체 생성에 대해서는 걱정할 필요가 없습니다. 이 개체가 없는 경우 MFC 가

이 개체를 엽니다. DAO 데이터베이스 클래스는 여러 작업 영역을 가질 수 있도록 지원합니다.

또한 Workspace 개체가 범위를 벗어나거나 데이터베이스 세션이 완료되기 전에 닫히는 것에 대해 걱정할

필요가 없습니다. 작업 영역 포인터를 사용하여 Workspaces 컬렉션, Databases 컬렉션, 데이터베이스

엔진의 속성 등을 액세스할 수 있습니다.

CDaoDatabase

CDaoDatabase 는 ODBC 기반 CDatabase 클래스 구조와 유사합니다. 또한 CDaoDatabase 는

데이터베이스 연결을 캡슐화합니다. 항상 ODBC 를 사용할 필요가 없기 때문에 대부분의 데스크톱 데이터

원본에 대해 경로로 위치를 표시합니다. CDaoDatabase 는 tabledef 및 querydef 개체를 저장할 수

있으므로 개발자에게 매우 편리합니다. CDaoDatabase 는 로컬 및 원격 데이터 원본에서 모두

사용됩니다. 나중에 사용할 수 있는 데이터 원본의 목록이 나옵니다.

Database 개체는 또한 세션 기간 동안 유지됩니다. 필요하면 데이터베이스 연결을 명시적으로 닫을 수

있습니다. 단순히 비교하면 CDatabase 클래스는 21 개의 구성원 함수를 가지고 있고 CDaoDatabase

는 26 개의 구성원 함수를 가지고 있습니다. 구성원 함수는 서로 비슷하지만 CDaoDatabase 가 약간 더

많습니다.

ODBC 데이터베이스 클래스에는 CDaoTableDef 와 일치하는 클래스가 없습니다. TableDef 개체를

사용하면 Microsoft Access 테이블(기본 테이블)이건 연결된 테이블이건 상관없이 데이터베이스의

구조를 조사할 수 있습니다. DAO 를 사용하여 테이블을 직접 열면 필드와 인덱스를 외부 데이터 원본에

추가할 수 있습니다. 테이블을 연결하면 구조를 조사할 수 있지만 변경할 수는 없습니다. 테이블에서

레코드 집합을 작성할 수 있습니다. 이렇게 하면 Seek 라는 고속 검색 구성원 함수를 사용하는 것을

포함하여 여러 가지 장점이 있습니다.

CDaoTableDef::CanUpdate 를 호출하여 테이블의 데이터를 편집할 수 있는지 판별하려면

CDaoTableDef 를 사용합니다. MFC 는 여러분 대신 DAO Fields 및 Indexes 컬렉션을 관리합니다. CDaoTableDef 는 TableDefs 컬렉션에 테이블을 추가하는 옵션이 있으며 다른 개체들은 모두 자동으로

추가됩니다.

레코드 검색에 사용하는 SQL 은 CDaoQueryDef 개체에 저장됩니다. 이 개체를 사용하면 "지난 달 몇

명의 고객이 비용을 지불했습니까?" 등과 같은 데이터에 대한 "쿼리"를 저장할 수 있습니다. 다음과 같은

방법으로 이 저장된 쿼리를 검색하고 사용할 수 있습니다.

CDaoQueryDef 개체로 포인터를 전달하여 레코드 집합을 생성합니다.

데이터를 이동하거나 변경하는 동작 쿼리를 직접 실행합니다. 동작 쿼리에는 append, delete, make-table 및 update 쿼리 등이 포함됩니다. Delete 및 update 쿼리는 기존 데이터를 변경하고

append 및 make-table 쿼리는 기존 데이터를 이동합니다. SQLPASSTHROUGH 쿼리를 실행합니다. SQL pass-through 쿼리는 Microsoft Jet

데이터베이스 엔진에 의해 해석되지 않고 바로 데이터베이스 서버로 보내지는 SQL 문입니다. SQL pass-through 쿼리를 사용하면 응용 프로그램에서 직접 데이터베이스 서버의 기능을 조작할 수

있습니다.

CDaoRecordset 은 ODBC 기반 CRecordset 클래스와 아주 흡사합니다. 레코드 집합은 다이너셋 및

스냅샷은 물론 테이블을 기반으로 할 수도 있습니다. 레코드 집합은 검색한 레코드와 데이터를 이동하는

방법을 모두 나타낸다는 사실을 기억하십시오. 데이터 이동 옵션으로는 Seek(테이블 형식 레코드 집합

전용), Find 및 Move 동작, AbsolutePosition 이 있으며 데이터 원본이 지원하는 경우 책갈피도

포함됩니다. 책갈피는 해당 식별자를 호출하여 특정 레코드로 복귀하는 데 사용하는 고유 식별자입니다.

CDaoRecordset 에는 MFC DAO 데이터베이스 클래스의 많은 기능이 포함되어 있습니다. CDaoRecordset 이 91 개의 구성원 함수를 가진 반면 CRecordset 은 44 개의 구성원 함수만 가지고

있습니다. 이 추가 기능들은 필드 값의 검색, 캐시, 설정, 복원 및 레코드 집합 속성의 설정 및 복원에

사용됩니다.

CDaoRecordView 와 CRecordView 클래스는 거의 같은 기능을 가지고 있습니다. 또한 모두

CFormView 를 기반으로 합니다. 폼 보기는 대화 상자 템플릿을 창의 클라이언트 영역으로 확장하여

컨트롤 추가 및 필드 데이터 표시를 쉽게 만든다는 사실을 기억하십시오. AppWizard 및 ClassWizard 는

폼 기반 데이터 표시를 지원합니다. AppWizard 를 사용하여 초기 응용 프로그램을 생성하면

데이터베이스의 열이 자동으로 구성원 변수에 바운드됩니다.

예외 처리는 DAO 데이터베이스 클래스와 약간 다릅니다. CDaoException 클래스는 기본 DAO OLE 개체의 오류 메시지를 반환합니다. 대부분의 경우 ODBC 기반 클래스를 사용할 때보다 더 많은 오류

정보를 검색할 수 있습니다. MFC 에서 모든 DAO 오류는 CDaoException 형식의 예외로 표현됩니다.

이러한 형식의 오류가 발견되면 CDaoException 구성원 함수를 사용하여 데이터베이스 엔진의 Errors 컬렉션에 저장된 모든 DAO 오류 개체로부터 정보를 검색할 수 있습니다. 오류가 발생할 때마다 하나

이상의 오류 개체가 Errors 컬렉션에 포함됩니다. 다른 DAO 동작이 오류를 생성하면 Errors 컬렉션이

지워지고 새 오류 개체가 컬렉션에 포함됩니다.

CDaoFieldExchange 클래스는 DAO 데이터베이스 클래스에 의해 사용되는 DAO DFX 루틴을

지원합니다. 이 클래스는 사용자 정의 데이터 형식의 데이터 교환 루틴을 작성할 경우에 사용하며 그 밖의

경우에는 이 클래스를 직접 사용하지 않습니다. DFX 는 CDaoRecordset 개체의 필드 데이터 구성원과

데이터 원본에서 현재 레코드의 대응되는 필드 사이에 데이터를 교환합니다. DFX 는 데이터 원본의 양방향

모두에서 교환을 관리합니다. 사용자 정의 DFX 루틴에 대한 자세한 내용은 온라인 설명서의 MFC 단원, Technical Note 53 을 참고하십시오.

CDaoFieldExchange 개체는 DAO 레코드 필드 교환에 필요한 컨텍스트 정보를 제공합니다. CDaoFieldExchange 개체는 매개 변수 및 필드 데이터 구성원 바인딩과 현재 레코드의 필드에서

다양한 플래그 설정 등을 포함한 많은 기능을 지원합니다. DFX 기능은 enum 으로 정의된 레코드 집합-클래스 데이터 구성원 형식에서 수행됩니다. CDaoFieldExchange 의 FieldType 가능한 FieldType

값은 다음과 같습니다.

필드 데이터 구성원의 경우 CDaoFieldExchange::outputColumn.

매개 변수 데이터 구성원의 경우 CDaoFieldExchange::param.

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

그림 1 MFC ODBC 데이터베이스 클래스

이것은 이미 알고 있는 ODBC 기반 데이터베이스 클래스의 그림입니다. 상단의 막대는 ODBC 와 대화하는

ODBC 기반 MFC 클래스를 나타냅니다. 각 데이터베이스의 ODBC 드라이버는 SQL 호출을 해석하고 각

데이터 원본에 맞게 변환합니다. ODBC 의 유연성을 보여 주는 다양한 데이터 원본이 대응되는 드라이버와

함께 그림 하단에 표시되어 있습니다.

그림 2 는 DAO 데이터베이스 클래스를 나타냅니다. 이 클래스는 OLE 를 통해 DAO 와 통신하고 DAO 는

Jet 데이터베이스 엔진과 대화합니다. Jet 데이터베이스 엔진은 다양한 데스크톱 데이터 원본과 통신하는

데 사용되는 별도의 DLL 을 가지고 있습니다.

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

그림 2 MFC DAO 데이터베이스 클래스 - 데스크톱 데이터 원본

Microsoft Jet 데이터베이스 엔진은 FoxPro 데이터베이스 및 Paradox 와 같은 데이터 원본을 직접 열

수 있습니다. 그러나 이 데이터 원본의 구조를 변경할 필요가 없으면 이 테이블을 Microsoft Access 데이터베이스에 연결하는 것이 실제로 더 효과적입니다. 위의 예제에서 FoxPro 와 Paradox 테이블을

별도의 위치에 나타낸 이유는 이것 때문입니다. 점선은 데이터 원본을 직접 여는 것도 가능하지만 그다지

효율적이지 않음을 의미합니다.

연결 테이블이 나타나고 Microsoft Jet 데이터베이스의 다른 테이블처럼 동작합니다(원격 데이터의

연결과 검색에서 약간의 차이가 있지만). 원격 데이터 원본으로 연결을 설정하고 유지하는 데 필요한

정보는 테이블 정의에 저장됩니다.

반대로 테이블을 직접 열 때는 각 세션의 처음에 데이터 원본으로 연결을 설정하기 위한 연결 정보를

제공해야 합니다. 원격 데이터 원본으로 연결을 설정하는 데 필요한 정보는 Microsoft Jet 데이터베이스에

저장되지 않습니다. 테이블을 직접 여는 경우에는 CDaoTableDef::Create 를 사용하고 데이터 원본, 사용자 이름, 암호, 데이터베이스 이름 등의 연결 정보를 제공해야 합니다.

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

그림 3 SQL 데이터베이스를 포함한 MFC DAO 데이터베이스 클래스

DAO 데이터베이스 클래스를 사용하면 Microsoft SQL Server 및 ORACLE ODBC 등의 서버 형식

데이터베이스를 이용할 수 있습니다. 그림 3 은 모든 형식의 데이터 원본을 이용하는 경우를 나타냅니다.

마지막으로 그림 4 는 MFC 데이터베이스 클래스를 나타냅니다. MFC 막대와 ODBC 막대는 두 집합의

MFC 데이터베이스 클래스를 선택적으로 사용할 수 있도록 설계되었음을 의미합니다. 모든 형식의 데이터

원본을 이용할 수 있는 옵션이 있지만 두 집합에서 MFC 데이터베이스 클래스를 혼용할 수는 없습니다.

현재 브라우저에서 인라인 프레임을 지원하지 않을 경우 여기를 누르면 별도의 페이지에서 볼 수 있습니다.

그림 4 MFC 데이터베이스 클래스

ODBC 데이터베이스 클래스의 데이터 원본 옵션

MFC ODBC 클래스를 사용하여 응용 프로그램을 작성하는 경우 ODBC 드라이버를 가진 모든 데이터

원본을 연결할 수 있습니다. ODBC 드라이버 관리자 및 ODBC 드라이버의 기능은 해당 클래스를 사용하여

작성하는 응용 프로그램에서 투명하지만 개별 드라이버의 기능은 응용 프로그램의 기능에 영향을 줍니다.

일반적으로 MFC 다이너셋(앞으로 전용 레코드 집합 제외)은 수준 2 API 를 적용한 ODBC 드라이버가

필요합니다. 데이터 원본의 드라이버에 수준 1 API 집합이 적용된 경우 업데이트가 가능한 읽기 전용

스냅샷과 앞으로 전용 레코드 집합을 사용할 수 있지만 다이너셋은 사용할 수 없습니다. 그러나 수준 1 드라이버가 확장 패치 및 키집합 구동 커서를 지원하면 다이너셋을 사용할 수 있습니다.

ODBC Desktop Driver Pack 버전 3.0 은 수준 2 ODBC API 호출 SQLExtendedFetch 를

지원합니다.

AppWizard 와 ClassWizard 는 자동으로 데이터 원본의 열을 응용 프로그램의 구성원 변수에 정적으로

바인드합니다. 이것은 응용 프로그램과 데이터 원본을 연결하는 가장 쉬운 방법이지만 유연한 방법은

아닙니다. CFieldExchange 클래스를 사용하여 사용자 정의 RFX 호출을 응용 프로그램에 추가할 수

있습니다. 자세한 내용은 Technical Note 43: RFX Routines 를 참조하십시오.

데이터베이스 열을 동적으로 바인드하는 것도 고려할 수 있습니다. 가장 일반적인 단계는 다음과

같습니다.

1. 기본 레코드 집합 개체를 작성합니다. 옵션으로 열려 있는 CDatabase 개체로 포인터를

전달하거나 다른 방법으로 열 레코드 집합에 연결 정보를 제공할 수 있습니다.

2. 동적으로 열을 추가하는 단계를 진행합니다. 3. 기본 레코드 집합을 엽니다.

레코드 집합은 레코드를 선택하고 RFX 를 사용하여 "정적" 열(레코드 집합 필드 데이터 구성원으로 매핑된

열)과 동적 열(할당한 추가 저장 장치로 매핑된 열)을 모두 바인드합니다.

DAO 데이터베이스 클래스의 데이터 원본 옵션

이제 DAO 데이터베이스 클래스를 사용하여 연결할 수 있는 데이터 원본과 정적 및 동적으로 열을

바인드하고 레코드를 더블버퍼링하는 방법에 대해 알아봅시다.

Microsoft Access 데이터베이스는 Jet 를 사용하기 때문에 당연히 가장 빠르게 액세스할 수 있습니다. Microsoft Access 97 은 DAO 버전 3.5 의 데이터베이스 형식을 가지고 있습니다. Microsoft Access 97 데이터베이스를 사용하면 가장 빠른 성능을 얻을 수 있습니다.

Jet 는 별도의 DLL 을 사용하여 Microsoft Jet 버전 1.x 및 2.0 데이터베이스를 액세스합니다. Microsoft Jet 버전 3.0 에서는 저장 엔진과 형식이 완전히 달라졌습니다. 중요한 변경 사항은 Microsoft Jet 버전 3.0은 버전 2.0 데이터베이스를 외부 ISAM 으로 다룬다는 점입니다. 이것은 성능에 영향을 주므로 아직

Microsoft Access 데이터베이스를 업그레이드하지 않은 경우 그대로 두십시오.

설치 가능한 ISAM 데이터베이스 및 ODBC 데이터 원본을 액세스할 수도 있습니다. FoxPro 및 dBASE 와

같은 ISAM(인덱스된 순차적 액세스 방법) 데이터베이스는 최상의 성능을 위해 Access 데이터베이스에서

직접 열거나 연결할 수 있습니다. 다음은 DAO 가 액세스할 수 있는 데이터 원본의 목록입니다.

Microsoft FoxPro, 버전 2.0, 2.5, 2.6. 버전 3.0 에서는 데이터를 가져오거나 내보낼 수 있지만

개체를 생성할 수는 없습니다.

dBASE III, dBASE IV, dBASE 5.0 Paradox, 버전 3.x, 4.x, 5.x Btrieve, 버전 5.1x, 6.0 Microsoft Excel 버전 3.0, 4.0, 5.0, 7.0, 8.0 워크시트

Lotus WKS, WK1, WK3, WK4 스프레드시트

텍스트 파일

Microsoft Access 버전 1.x, 2.0, 및 7.0 데이터베이스는 이 범주에 속합니다.

ODBC 를 통해 SQL Server 및 Oracle 과 같은 ODBC 데이터 원본을 사용할 수 있으므로 이러한 데이터

원본에 대해 DAO 를 사용할 수 있는 옵션이 있습니다. ODBC 데이터 원본은 적절한 ODBC 드라이버가

있는 DBMS 입니다. Visual C++ 버전 2.0 이상의 경우 32 비트 ODBC 드라이버가 필요합니다(예외적으로 Win32 는 16 비트 ODBC 드라이버가 필요). 다음은 이 버전의 Visual C++에 포함된 ODBC 드라이버 목록입니다.

SQL Server

Microsoft Access Microsoft FoxPro Microsoft Excel dBASE Paradox 텍스트 파일

Microsoft Desktop Database Drivers 버전 3.0(목록의 마지막 6 개 항목)은 위의 데이터 원본에 대해

최상의 성능을 나타냅니다. 이들은 32 비트 전용입니다.

SQL Server 와 같은 외부 데이터 원본을 Microsoft Access 테이블에 연결하는 것은 데이터 액세스를

처리하는 가장 효율적인 방법입니다. 응용 프로그램을 원격 데이터 원본에 연결하기 전에 응용 프로그램의

사용자가 원격 데이터 원본을 액세스할 수 있고 응용 프로그램이 원격 데이터 원본의 보안 문제를 올바로

처리할 수 있도록 설계해야 합니다. 또한 응용 프로그램이 대소문자를 구분하는 데이터 원본과 올바로

통신하고 설치 가능한 ISAM 이 액세스할 데이터 원본에 적합하게 초기화되었지 확인해야 합니다. 마지막으로 비 Jet 데이터 원본을 액세스할 때 코드가 Microsoft Jet 데이터 원본에 특정한 개체나 호출을

사용하지 않는지 검사해야 합니다.

연결을 설정하는 가장 쉬운 방법은 Microsoft Access 버전 2.0 에서 File/Attach Table 명령을

사용하거나 Microsoft Access 95 및 Microsoft Access 97 에서 File/Get External Data/Link Tables 명령을 사용하는 것입니다.

연결 정보는 사용하고 있는 기본 테이블(.MDB)에 저장됩니다. 외부 데이터의 위치를 이동하는 경우

Microsoft Access 를 사용하거나 코드에서 CDaoTableDef::RefreshLink 를 호출하여 연결을

재설정해야 합니다.

DAO RFX 메커니즘은 ODBC 기반 데이터베이스 클래스의 RFX 와 동일한 방식으로 동작합니다. 레코드

집합 개체의 필드 데이터 구성원은 한 레코드의 선택한 열들을 저장하는 "편집 버퍼"를 공동으로

사용합니다. 레코드 집합이 처음 열리고 레코드를 읽으려고 하면 DFX 는 선택한 각 열을 알맞은 필드

데이터 구성원의 주소로 바인드합니다. 레코드 집합이 레코드를 업데이트하면 DFX 는 DAO 를 호출하여

데이터베이스 엔진에 적절한 명령을 보냅니다. DFX 는 필드 데이터 구성원의 정보를 사용하여 데이터

원본에 작성할 열(필드)을 지정합니다.

마법사는 정적 열 바인딩을 지원합니다. ODBC 기반 클래스처럼 자신의 DFX 호출을 추가할 수 있습니다. 먼저 바인드된 각 필드와 매개 변수에 대해 CDaoRecordset 파생 클래스에 구성원을 추가해야 합니다. 이어서 CDaoRecordset::DoFieldExchange 를 재정의합니다. 구성원의 데이터 형식은 중요합니다. 데이터베이스에 있는 필드의 데이터와 일치하거나 최소한 해당 데이터 형식과 호환되어야 합니다. MFC Technical #53 에 이 과정이 상세히 설명되어 있습니다.

CDaoFieldExchange 클래스는 DAO 데이터베이스 클래스에 의해 사용되는 DAO DFX 루틴을

지원합니다. 사용자 정의 데이터 형식에 대해 데이터 교환 루틴을 작성할 경우에 이 클래스를 사용합니다. CDaoFieldExchange 개체는 DAO RFX 에 필요한 컨텍스트 정보를 제공합니다. CDaoFieldExchange 개체는 매개 변수 및 필드 데이터 구성원 바인딩과 현재 레코드의 필드에서

다양한 플래그 설정 등을 포함한 많은 기능을 지원합니다.

DAO 데이터베이스 클래스에서 동적 바인딩

ODBC 기반 클래스를 사용하면 동적으로 열을 바인드할 수 있지만 MFC 클래스에서는 이 기능이 지원되지

않습니다. 동적 바인딩은 DAO 데이터베이스 클래스에 내장되어 있으며 비교적 사용하기 쉽습니다.

전체 레코드 대신 레코드의 일부만 검색하는 등 성능을 최적화할 수 있는 기타 기능들이 있습니다. 응용

프로그램을 최적화하는 방법에 대해서는 잠시 후에 다루겠습니다.

DFX 와 동적 바인딩은 상호 배타적인 옵션이 아닙니다. DAO 데이터베이스 클래스에서 정적 바인딩과

동적 바인딩 호출을 혼용하면 최대의 효율을 얻을 수 있습니다.

DAO 데이터베이스 클래스에서 더블버퍼링

MFC 의 CDaoRecordset 클래스에서 더블버퍼링은 레코드 집합의 현재 레코드가 변경되면 간단히

탐지할 수 있는 메커니즘입니다. DAO 레코드 집합과 함께 더블버퍼링을 사용하면 새 레코드를 추가하거나

기존의 레코드를 편집하는 데 필요한 작업을 줄일 수 있습니다. 기본값으로 MFC DAO 레코드 집합은 편집

버퍼의 보조 복사본을 유지합니다(공동으로 사용하는 레코드 집합 클래스의 필드 데이터 구성원. DAO Help 는 일치하는 버퍼를 "복사본 버퍼"라고 부름). 데이터 구성원을 변경하면 MFC 는 복사본("더블버퍼")과 비교하여 변경을 탐지합니다.

데이터 복사본을 유지하지 않는 더블버퍼링의 대안은 현재 레코드 필드를 편집할 때 추가적인 함수 호출이

필요합니다.

더블버퍼링은 항상 ODBC 기반 데이터베이스 클래스의 일부로 사용되어 왔습니다. DAO 데이터베이스

클래스의 경우 효율성을 높이기 위해 이 메커니즘을 사용하지 못하도록 설정할 수 있습니다.

이 메커니즘의 마스터 스위치는 m_bCheckCacheForDirtyFields 또는 간단히 "changed"라고

합니다. 이 스위치를 켜면 필드 전체나 일부에 대해 더블버퍼링을 사용하지 못하도록 설정할 수 있습니다. 이 마스터 스위치를 끄면 전체 더블버퍼링 메커니즘을 사용할 수 없게 됩니다.

메모 필드, 그림 필드 및 기타 BLOB(Binary Large Object)의 경우에 더블버퍼링 기능을 사용하지

못하도록 설정하면 편리합니다.

DAO SDK 클래스

DAO SDK 는 MFC DAO 데이터베이스 클래스와 구분되는 일부 C++ 데이터베이스 클래스를 포함하고

있습니다. 이 C++ 클래스는 DAO 계층 구조에서 개별 개체를 캡슐화합니다. DAO SDK C++ 클래스를

MFC DAO 데이터베이스 클래스와 함께 사용할 수도 있지만 DAO SDK C++ 클래스는 연산자 오버로드의

경우에 MFC 지침을 따르지 않으므로 이 클래스들을 함께 사용할 때는 주의해야 합니다. 자세한 내용은

Microsoft Systems Journal 1996 년 1 월판의 "DAO of Databases: Using Data Access Objects and the Jet Engine in C++" 기사를 참고하십시오.

다음 표는 DAO SDK 클래스와 MFC DAO 데이터베이스 클래스의 특징을 비교한 것입니다.

DAO SDK 데이터베이스 클래스

MFC DAO 데이터베이스 클래스

Visual Basic 으로부터 간단히

마이그레이션

MFC ODBC 데이터베이스 클래스로부터 간단히

마이그레이션

DAO 의 OLE 자동화 개체로 직접 매핑 MFC 표준 2 단계 작성 준수

더 많은 Jet/DAO 기능 AppWizard 및 ClassWizard 지원

MFC 표준 2 단계 작성을 준수하지 않음 복잡한 DAO 기능 숨김

DAO SDK 클래스를 사용하면 Visual Basic 의 익숙한 클래스들을 사용할 수 있지만 이 클래스들은 MFC를 준수하지 않습니다. 이미 MFC ODBC 데이터베이스 클래스를 사용하고 있는 개발자의 경우 MFC DAO 클래스의 아키텍처와 사용법이 더 쉽게 느껴질 것입니다.

MFC 데이터베이스 클래스 비교

먼저 두 클래스 집합의 공통적인 데이터베이스 기능에 대해 알아봅시다.

모두 레코드 집합을 통한 스크롤 지원

o ODBC 클래스는 기본 드라이버에 의존합니다.

o DAO 클래스는 MDB 를 더 잘 지원하고 설치 가능한 ISAM 에 유용하며 ODBC 데이터베이스 클래스와 마찬가지로 서버 기반 데이터를 지원합니다.

모두 트랜잭션 지원

o Database 수준의 ODBC 클래스.

o Workspace 수준의 DAO 클래스. 레코드 집합 업데이트 기능은 거의 동일합니다. 모두 업데이트 동안 레코드 잠금을 지원합니다. 두 클래스 집합 모두 필드 데이터 변경 탐지를 지원합니다. 모두 Move 동작을 사용합니다.

CDatabase 및 CDaoDatabase 는 모두 데이터 원본이 트랜잭션을 수용하는지 여부를 탐지할

수 있습니다. ODBC 데이터베이스 클래스에서 트랜잭션 요구 사항은 MFC 4.2 처럼 매우 느슨합니다. 모두 데이터베이스 개체를 통해 사전 정의된 쿼리 만료 시간을 설정할 수 있습니다. 모두 직접 SQL 문을 실행할 수 있습니다.

추가적인 ODBC 데이터베이스 클래스 기능

ODBC 데이터베이스 클래스는 MFC 4.2 처럼 멀티스레드가 가능합니다. 이 기능을 활용하려면

멀티스레드 ODBC 드라이버를 사용해야 합니다. DAO 는 AMT(Apartment-Model Threaded)를

도입할 예정이지만 그 시기는 알 수 없습니다.

MFC 4.2 에서 많은 원시 패치 기능이 새로 추가되었습니다. 특별한 검색 기능이 추가되었습니다.

많은 요청이 있었으므로 콘솔 데이터베이스 응용 프로그램을 위한 지원을 개선했습니다. CDatabase::OpenEx 의 새로운 옵션은 다음과 같습니다.

CDatabase::noOdbcDialog 연결 정보가 충분히 제공되어도 ODBC 연결 대화

상자를 표시하지 않습니다.

CDatabase::forceOdbcDialog 항상 ODBC 연결 대화 상자를 표시합니다.

추가적인 DAO 데이터베이스 클래스 기능

Workspace, TableDef 및 QueryDef 개체는 DAO 데이터베이스 클래스의 고유 개체입니다. ODBC 데이터베이스 클래스에는 이와 같은 개체가 없습니다.

CDaoTableDef 및 CDaoQueryDef 기능은 CATALOG2 예제에서 볼 수 있는 것처럼

일반적으로 ODBC 를 직접 호출하여 새로 생성할 수 있습니다. CDaoDatabase 는 TableDef, QueryDef 및 Relation 의 생성을 지원합니다.

CDaoRecordset 은 다음과 같은 뛰어난 탐색 기능을 가지고 있습니다.

찾기 연산

백분율 위치

검색

다량의 레코드 패치 기능 및 관련 캐시 기능 내장

CDaoTableDef 개체를 사용하여 런타임으로 필드와 인덱스를 생성하는 기능은 지원하는

데이터 원본이 다양하므로 상당히 유용합니다.

CDaoQueryDefs 는 필드와 인덱스를 사용하여 생성하고 반복 사용을 위해 저장할 수

있습니다. CDaoQueryDefs 는 ODBC 시간 제한도 제어할 수 있습니다.

MFC 데이터베이스 응용 프로그램 최적화

종종 간과하기 쉽지만 응용 프로그램의 성능을 개선할 수 있는 여러 방법들이 있습니다. 예를 들어, 네트워크에서 수행하는 작업을 알면 데이터 검색 기능을 개선하거나 중단할 수 있습니다(예: 비동기 쿼리).

사용하는 ODBC 드라이버의 종류에 따라 네트워크의 성능에 영향을 줄 수도 있습니다.

단일 계층 드라이버는 비 SQL 기반 데이터베이스에서 사용하도록 설계되었습니다. 데이터베이스

파일은 드라이버에 의해 직접 처리됩니다. 드라이버는 SQL 문을 처리하고 데이터베이스에서 정보를

검색합니다. SQL 문은 분석되고 기본 파일 기능으로 변환된 후에 데이터베이스로 전달됩니다. xBASE 파일을 조작하는 드라이버는 단일 계층 구현의 한 예입니다.

단일 계층 드라이버는 전송되는 SQL 문 집합을 제한할 수도 있습니다. 단일 계층 드라이버가

지원해야 하는 최소한의 SQL 문 집합은 ODBC SDK 프로그래머 안내서의 부록 C, "SQL 문법"에

정의되어 있습니다. 단일 계층 드라이버는 SQL 문을 분석하여 기본 파일 동작으로 변환하기 때문에 대개 Microsoft

FoxPro 와 같은 고유 DBMS 도구를 사용하는 것보다 느립니다. 이 과정의 최적화 방법에 따라 속도가

달라집니다. 두 단일 계층 드라이버에서 속도의 차이는 대개 최적화 방법에 기인합니다. 다계층 구성에서 드라이버는 요청을 처리하는 서버로 해당 요청을 보냅니다. 요청은 SQL 이나

DBMS 특정 형식이 될 수 있습니다. 전체 설치 프로그램이 단일 시스템에 있는 경우도 있지만 대개

여러 플랫폼으로 분산됩니다. 응용 프로그램, 드라이버 및 드라이버 관리자는 일반적으로

클라이언트라고 부르는 한 시스템에 배치됩니다. 데이터베이스와 데이터베이스를 제어하는

소프트웨어는 서버라고 하는 다른 시스템에 배치됩니다. 다음과 같은 두 가지 종류의 다계층

드라이버가 있습니다. 2 계층 및 3 계층(또는 게이트웨이). 자세한 내용은 Microsoft Developer Network CD 에 있는 Colleen Lambert 의 기사 "ODBC: Architecture, Performance, and

Tuning"을 참조하십시오.

ODBC 데이터베이스 및 레코드 집합 및 개체 최적화

CDatabase 개체를 열면 사용자에게 선택 대화 상자를 표시하는 NULL 이라고 하는 데이터 원본을

제공할 수 있습니다. MFC ODBC 데이터베이스 클래스는 데이터베이스에 대한 배타적 액세스를 지원하지

않으므로 항상 연결이 공유됩니다. 그러나 데이터베이스를 읽기 전용으로 열 수 있습니다. 이렇게 하면

CDatabase 개체로부터 파생된 모든 레코드 집합도 읽기 전용이 된다는 점을 기억하십시오. 다음은 콘솔

응용 프로그램을 더 쉽게 작성할 수 있는 옵션들입니다. 이 새 옵션들은 고객이 가장 많이 요청한 사항 중

하나입니다.

CDatabase::noOdbcDialog 연결 정보가 충분히 제공되어도 ODBC 연결 대화 상자를

표시하지 않습니다.

CDatabase::forceOdbcDialog 항상 ODBC 연결 대화 상자를 표시합니다.

응용 프로그램과 함께 ODBC Cursor Library 를 로드하는 옵션도 있습니다. 기본 드라이버의 기능에 따라

이 옵션이 필요하지 않을 수도 있습니다. Cursor Library 는 기본 ODBC 드라이버의 일부 기능을

마스크하여 다이너셋의 사용을 효과적으로 방지합니다(드라이버에서 이 기능을 지원하는 경우). Cursor Library 가 로드될 때 지원되는 유일한 커서는 정적 스냅샷 및 "forwardOnly" 커서입니다.

열린 CRecordset 개체의 형식은 응용 프로그램의 성능에 상당한 영향을 미칩니다. 양방향 스크롤이

가능한 동적 레코드 집합을 원하는 경우 CRecordset::dynaset 형식을 선택합니다. 양방향 스크롤이

가능한 정적 레코드 집합을 원하는 경우 CRecordset::snapshot 형식을 선택합니다. 데이터를

스크롤할 필요가 없으면 앞으로만 스크롤할 수 있는 읽기 전용 레코드 집합을 생성하는

CRecordset::forwardOnly 형식을 선택합니다. 새로운 CRecordset::dynamic 형식 레코드

집합은 양방향 스크롤이 가능한 레코드 집합입니다. 다른 사용자에 의해 구성원 자격, 순서 및 데이터 값이

변경되는 것을 볼 수 있고 패치 동작이 이어집니다. 그러나 ODBC 드라이버는 이러한 형식의 레코드

집합을 지원하지 않는다는 점에 유의하십시오.

CRecordset 은 추가로 다음과 같은 옵션을 가지고 있습니다.

CRecordset::none 설정된 옵션 없음. 기본적으로 레코드 집합은 Edit 나 Delete 를 통해

업데이트할 수 있으며 AddNew 를 통해 새 레코드를 추가할 수 있습니다. 업데이트 가능 여부는

지정한 옵션은 물론 데이터 원본에 따라 달라집니다.

CRecordset::appendOnly 레코드 집합에서는 Edit 나 Delete 를 사용할 수 없고

AddNew 만 사용할 수 있습니다. CRecordset::readOnly 레코드 집합을 읽기 전용으로 엽니다. CRecordset::optimizeBulkAdd 미리 작성된 SQL 문을 사용하여 한 번에 많은 레코드

집합을 추가하는 작업을 최적화합니다. 이 옵션은 CRecordset::useMultiRowFetch 와 상호

배타적입니다. CRecordset::useMultiRowFetch 일괄 행 패치 구현을 통해 단일 패치 동작으로 여러 행을

검색할 수 있습니다. 이 옵션은 CRecordset::optimizeBulkAdd 와 상호 배타적입니다. CRecordset::useMultiRowFetch 를 지정하면 CRecordset::noDirtyFieldCheck 옵션이

자동으로 켜지고(더블버퍼링을 사용할 수 없음), 앞으로 전용 레코드 집합에서

CRecordset::useExtendedFetch 옵션이 자동으로 켜진다는 점에 유의하십시오. CRecordset::skipDeletedRecords 레코드 집합을 검색할 때 삭제된 레코드를 건너뜁니다.

이렇게 하면 특정 관련 패치에서 성능이 느려집니다. 이 옵션은 앞으로 전용 레코드 집합에서는

유효하지 않습니다. CRecordset::skipDeletedRecords 는 레코드 집합에서 행이 삭제된 것을

탐지하는 드라이버 패킹과 유사합니다. CRecordset::useBookmarks 책갈피가 지원되는 경우 레코드 집합에서 이 기능을 사용할 수

있습니다. 책갈피를 사용하면 데이터 검색이 느려지지만 데이터를 탐색할 때 성능을 높일 수

있습니다. 앞으로 전용 레코드 집합에서는 사용할 수 없습니다. CRecordset::noDirtyFieldCheck 사용 필드 자동 검사 기능(더블버퍼링)을 끕니다. 이렇게

하면 성능이 개선되지만 SetFieldDirty 및 SetFieldNull 구성원 함수를 호출하여 사용 필드를

직접 표시해야 합니다. CRecordset::executeDirect 미리 작성된 SQL 문을 사용하지 않습니다. Requery 구성원

함수가 호출되지 않는 경우에 이 옵션을 지정하면 성능을 개선할 수 있습니다. CRecordset::useExtendedFetch SQLFetch 대신 SQLExtendedFetch 를

구현합니다. 이 옵션은 앞으로 전용 레코드 집합에서 일괄 행 패치를 구현하도록 설계되었습니다. 앞으로 전용 레코드 집합에서 CRecordset::useMultiRowFetch 옵션을 지정하면

CRecordset::useExtendedFetch 가 자동으로 켜집니다. CRecordset::userAllocMultiRowBuffers 사용자가 데이터 저장 버퍼를 할당합니다.

자신만의 저장소를 할당하려면 이 옵션을 CRecordset::useMultiRowFetch 와 함께 사용하며, 그 밖의 경우에는 프레임워크가 자동으로 필요한 저장소를 할당합니다.

필요하면 일괄 행 패치를 사용하여 성능을 높일 수 있습니다. 레코드 집합 개체를 열기 전에

SetRowsetSize 구성원 함수를 사용하여 행 집합 크기를 정의할 수 있습니다. 행 집합 크기는 단일

패치에서 검색해야 하는 레코드의 개수를 지정합니다. 일괄 행 패치가 구현된 경우 기본 행 집합 크기는 25입니다. 일괄 행 패치가 구현되지 않은 경우 행 집합 크기는 1 로 고정된다는 점에 유의하십시오.

행 집합 크기를 초기화한 후에 Open 구성원 함수를 호출합니다. 여기에서 dwOptions 매개 변수의

CRecordset::useMultiRowFetch 옵션을 지정해야 일괄 행 패치를 구현할 수 있습니다. CRecordset::userAllocMultiRowBuffers 옵션을 추가로 설정할 수 있습니다. 일괄 레코드 필드

교환 메커니즘은 배열을 사용하여 패치 동안 검색된 여러 데이터 행을 저장합니다. 이 저장 버퍼는

프레임워크에서 자동으로 할당되거나 자신이 직접 할당할 수도 있습니다. CRecordset::userAllocMultiRowBuffers 옵션 지정은 할당을 한다는 의미입니다.

DAO 데이터베이스 및 레코드 집합 개체 최적화

CDaoDatabase 개체를 사용할 경우 기존 Microsoft Jet 데이터베이스 파일(.MDB) 이름인 문자열 식을

사용합니다. 파일 이름에 확장명이 포함된 경우 필요합니다. 네트워크에서 UNC(Uniform Naming Convention)를 지원하면 "\\\\MYSERVER\\MYSHARE\\MYDIR\\MYDB.MDB"처럼 네트워크 경로를

지정할 수도 있습니다.("\"는 C++에서 제어 문자로 사용되기 때문에 일반 문자로 표시하려면 이중

백슬래시가 필요합니다.) 이런 방식으로 데이터베이스를 사용하는 경우 몇 가지 고려할 사항들이

있습니다.

데이터베이스가 이미 다른 사용자가 배타적으로 액세스하도록 열려 있으면 MFC 는 예외를 만듭니다. 이

예외를 통해 사용자에게 데이터베이스를 사용할 수 없다는 것을 알릴 수 있습니다.

빈 문자열("")을 사용하여 데이터베이스를 열고 ODBC 데이터 원본에 연결하면, 사용자가 데이터베이스를

선택할 수 있도록 등록된 모든 ODBC 데이터 원본 이름 목록을 가진 대화 상자가 표시됩니다. ODBC 데이터 원본에 직접 연결하는 것은 피해야 합니다. 대신 연결 테이블을 사용합니다.

CDaoDatabase 개체는 배타적 액세스로 열 수 있습니다. 기본값으로 이 개체는 공유 액세스로

열립니다. 이 개체는 읽기 전용 데이터 원본으로 열거나 읽기/쓰기 액세스가 가능하도록 열 수 있습니다. CDaoDatabase 개체에서 파생된 모든 레코드 집합은 데이터베이스 개체의 읽기 기능을 상속 받습니다.

CRecordset 개체와 마찬가지로 CDaoRecordset 은 2 개 이상의 형식을 가지고 있습니다. dbOpenDynaset 을 선택하면 양방향 스크롤을 사용하는 다이너셋 형식의 레코드 집합이 열립니다. 이것은 기본값입니다. dbOpenSnapshot 을 선택하면 양방향 스크롤을 사용하는 스냅샷 형식의 레코드

집합이 제공됩니다. 마지막으로 dbOpenTable 을 선택하면 양방향 스크롤을 사용하는 테이블 형식의

레코드 집합을 열 수 있습니다. MFC ODBC 데이터베이스 클래스를 가진 테이블을 기반으로 하는 레코드

집합은 열 수 없습니다.

CDaoRecordset 개체는 CRecordset 개체와 유사한 옵션을 가지고 있습니다.

dbAppendOnly 새 레코드를 추가할 수만 있습니다(다이너셋 형식의 레코드 집합 전용). 이

옵션은 문자 그대로 레코드를 추가할 수만 있다는 의미입니다. MFC ODBC 데이터베이스 클래스는

레코드를 검색하고 추가할 수 있는 추가 전용 옵션을 가지고 있습니다.

dbForwardOnly 레코드 집합은 앞으로 전용 스크롤 스냅샷입니다. dbSeeChanges 편집하고 있는 데이터를 다른 사용자가 변경하면 예외를 생성합니다. dbDenyWrite 다른 사용자가 레코드를 수정하거나 추가할 수 없습니다. dbDenyRead 다른 사용자가 레코드를 볼 수 없습니다(테이블 형식의 레코드 집합 전용). dbReadOnly 레코드를 볼 수만 있으며 다른 사용자가 수정할 수 있습니다. dbInconsistent 일치하지 않는 업데이트가 허용됩니다(다이너셋 형식의 레코드 집합 전용). dbConsistent 일치하는 업데이트만 허용됩니다(다이너셋 형식의 레코드 집합 전용). 참고

dbConsistent 와 dbInconsistent 는 상호 배타적입니다. 주어진 Open 의 인스턴스에서 둘 중

하나만 사용할 수 있으며 모두 사용할 수는 없습니다.

ODBC 기반 데이터베이스 상호 작용 최적화

다음 권장 사항들은 ODBC 에 포함된 모든 상호 작용에 적용됩니다. 이 내용은 ODBC 데이터베이스

클래스에 적용되지만 DAO 가 ODBC 를 사용하여 데이터 원본과 통신하는 서버 기반 데이터를 가진 DAO 데이터베이스 클래스에도 적용됩니다. 이 권장 사항들의 많은 부분은 Microsoft Developer Network CD에 있는 Colleen Lambert 의 기사 "ODBC: Architecture, Performance, and Tuning"에서 발췌한

것입니다.

드라이버 적합 수준을 문의하여 가능하면 드라이버의 많은 기능들을 사용하십시오. 응용

프로그램을 다른 플랫폼으로 이식할 필요가 없으면 특정 드라이버의 기능을 주로 사용하여 응용

프로그램의 기능을 최적화할 수 있습니다.

데이터 원본 카탈로그 루틴 호출은 피하십시오. 이 작업은 상당히 많은 시간이 걸립니다. 일단

루틴을 호출한 후에 정보를 로컬로 캐시합니다. 확장성을 염두에 두고 데이터를 로컬이나 원격으로 적절히 배치합니다. 콤보 상자에 원격 데이터

원본을 넣지 마십시오. 스크롤하려면 SQLExtendedFetch 를 사용하십시오. 드라이버가 이 기능을 지원하는 경우

ODBC 데이터 원본을 스크롤하는 가장 빠른 방법입니다. 미리 작성된 SQL 문은 더 빠르게 실행됩니다. HSTMT 에 SQL 호출을 추가하는 데 시간을

투자하십시오. HSTMT 는 핸들이 해제될 때까지 해제되지 않습니다. SQLGetData 대신 SQLBindCol 을 사용하십시오. SQLBindCol 은 열의 저장 장소와 데이터

형식을 구분하므로 결과 집합에 대해 이 값을 다시 구할 필요가 없습니다. SQLTypeInfo 를 로컬로 캐시하십시오. 일부 데이터 원본은 이 호출을 저장 프로시저처럼

다루지만 실행하는 데 많은 시간이 걸립니다. 가능한 한 적은 연결을 사용하고 반복적인 연결 해제나 재연결을 피해야 합니다. ODBC 드라이버

관리자는 드라이버의 호출과는 별도로 연결을 준비하기 위해 호출한다는 사실을 기억하십시오. 이들은 모두 불필요한 작업이며 응용 프로그램의 수행 속도가 상당히 느려질 수 있습니다.

다계층 드라이버의 경우 블록 패치를 사용하십시오. 다계층 드라이버는 대개 네트워크 기능을

작업의 일부로 사용하며 SQLExtendedFetch 대신 SQLFetch 를 사용하므로 응용 프로그램이

네트워크 기능의 취약성에 노출됩니다. SQL 을 완전히 파악하여 쿼리를 최적화하십시오. 이것은 당연한 것처럼 보이지만 많은

프로그래머가 제한된 SQL 명령을 사용하고 있으며 SQL 문을 더 깊이 공부하면 더욱 빠른 응용

프로그램을 작성할 수 있습니다. 고성능 DBMS 를 사용하십시오. 처음에 설명했듯이 훌륭한 데이터 원본은 응용 프로그램의

성능과 기능의 기본입니다. 클라이언트가 최고의 성능을 발휘하도록 만드십시오.

다음 권장 사항들은 특히 DAO 데이터베이스 클래스에 적용됩니다. 이 목록에서 별표 항목들은 주로

ODBC(서버 기반) 데이터 원본과 상호 작용하는 항목들입니다.

가능하면 직접 테이블을 여는 대신 연결 테이블을 사용하십시오. DAO External: Working with External Data Sources 기사와 DAO 도움말의 Accessing External Databases with DAO 항목을

참고하십시오. 이 권장 사항은 목록의 모든 사항들 중에서 성능에 가장 중요한 영향을 미칩니다.*

데이터를 업데이트하지 않으려면 다이너셋 형식의 레코드 집합을 사용하지 마십시오. 앞으로만

스크롤하려면 앞으로 스크롤 스냅샷 형식의 레코드 집합을 사용하십시오. 레코드를 불필요하게

스크롤하지 말고 큰 테이블의 마지막 레코드로 점프하는 것을 피하십시오. 필요한 데이터만 검색하고 표시하십시오. 제한된 쿼리를 사용하여 검색할 레코드의 수를

제한하고 필요한 열만 선택합니다. 이렇게 하려면 네트워크로 전송하는 데이터의 크기가 더 작아야

합니다. 캐시를 사용하십시오. MFC 는 CDaoRecordset 클래스에서 지정된 개수의 레코드 캐시를

지원합니다. 이렇게 하면 데이터를 캐시에서 검색할 때 처음에는 시간이 더 걸리지만 캐시에서

레코드를 이동하는 것이 각 레코드를 스크롤하면서 검색하는 것보다 빠릅니다.* MFC CDaoRecordset 개체의 더블버퍼링 옵션을 끄십시오. 이것은 외부 데이터 원본으로

작업할 때와 마찬가지로 성능을 개선하는 일반적인 방법입니다. 레코드 일괄 추가와 같은 일괄 동작의 경우 SQL PASS-THROUGH 쿼리를 사용합니다. SQL

pass-through 쿼리를 사용할 때 항상 동일한 연결에서 SQL pass-through 쿼리를 수행하는

동안에는 연결 정보를 한 번만 설정하면 됩니다.*

로컬로 실행될 수 있는 쿼리의 사용을 피하십시오.* 사용자 정의 함수를 원격 열 인수와 함께 사용하지

마십시오. 유형이 다른 조인(2 개의 데이터베이스에 있는 테이블의 조인)은 인덱스 열에서만

사용하십시오. 이렇게 하면 일부 프로세싱이 로컬로 수행됩니다. 외부 데이터를 액세스할 때

Microsoft Jet 데이터베이스 엔진은 외부 데이터베이스가 작업을 수행할 수 없는 경우에만 데이터를

로컬로 처리합니다. 로컬로 수행되는 쿼리 연산에는 다음과 같은 것들이 있습니다.

DISTINCT 술어와 함께 쿼리의 상단에서 WHERE 절 제한. 종종 쿼리를 다시 배열하여

합계를 계산하거나 DISTINCT 쿼리를 다른 모든 연산 뒤에 배치할 수 있습니다.

원격으로 처리할 수 없는 연산을 포함하고 있는 WHERE 절. 원격 열을 포함한 사용자

정의 함수 등. (이 경우에 원격으로 처리할 수 없는 WHERE 절의 일부만 로컬로 처리된다는 점에

유의하십시오.) 다른 데이터 원본의 테이블 조인. 단순히 다른 데이터 원본의 테이블 사이에 조인만

가지고 있는 것이 모든 프로세싱이 로컬로 발생한다는 의미는 아닙니다. 서버로 제한을 보내면

관련 행들만 로컬로 처리됩니다. 합계 함수나 DISTINCT 술어를 통한 조인. 조인을 올바로 수행하는 것은 고도의

작업이며 AVG, MAX, MIN 등의 합계 함수를 추가하거나 DISTINCT 를 포함하는 문은 쿼리를

느리게 할 뿐입니다.

ODBC 드라이버에 의해 지원되지 않는 구문을 포함하는 외부 조인. Desktop Database Driver 는 내부 조인은 물론 왼쪽 및 오른쪽 외부 조인도 지원합니다. 왼쪽 외부

조인의 오른쪽 테이블이나 오른쪽 외부 조인의 왼쪽 테이블은 내부 조인에서 사용될 수 있습니다. 완전한 중첩 외부 조인은 지원되지 않습니다.

다음 3 개의 항목은 특히 원격 데이터 원본으로부터 액세스하는 데이터에 적용됩니다.

원격으로 처리할 수 없는 연산을 포함하고 있는 DISTINCT 술어.

ORDER BY 인수(원격 데이터 원본이 이 인수를 지원하지 않는 경우). 원격으로 처리할 수 없는 연산을 포함하고 있는 ORDER BY 나 GROUP BY 인수. 원격으로 처리할 수 없는 식은 서버에서 계산할 수 없는 식을 말합니다. 원격으로 처리할

수 없는 출력 식(SELECT 절의 식)은 합계 쿼리, DISTINCT 쿼리 또는 UNION 쿼리에서 발생하지

않으면 쿼리를 로컬로 계산하지 않아도 됩니다. 기타 절(WHERE, ORDER BY, GROUP BY, HAVING 등)의 원격으로 처리할 수 없는 출력 식은 최소한 쿼리의 일부라도 로컬로 계산되어야

합니다. DISTINCT 옵션과 함께 쿼리의 상단에 있는 GROUP BY 인수. GROUP BY 절 다음에

SELECT DISTINCTROW 를 사용합니다.

다음 기능들은 알려진 모든 ODBC 액세스 서버에서 지원되지 않으며 대개 Microsoft Jet 의 특정 SQL 확장입니다.

다중 그룹화 수준과 함께 보고서에서 사용되는 인수 등의 다계층 GROUP BY 인수.

TOP 또는 TOP PERCENT 술어. 하나 이상의 합계 함수나 GROUP BY 절과 일치하는 ORDER BY 절을 가진 크로스탭

쿼리. 간단한 크로스탭 쿼리는 서버로 보낼 수 있습니다.

응용 프로그램 최적화를 위한 기타 리소스

DAO 의 MFC 구현 정보에 대한 내용은 가장 먼저 Visual C++과 함께 제공되는 설명서를 보십시오. Class

Library Reference 및 Programming with MFC 와 함께 MFC DAO 예제와 MFC Technical Notes 도

필수 자료입니다.

DAO 의 동작 원리에 대한 자세한 내용은 Microsoft Press 에서 발간한 Microsoft Jet Database Engine

Programmer's Guide 를 참고하십시오.

Microsoft Developer Network CD 의 다음 두 기사를 추천합니다.

Black, Neil, and Stephen Hecht. Jet Database Engine ODBC Connectivity.

여기에는 Microsoft Jet 에서 ODBC 를 사용하여 서버 데이터를 검색하는 방법이 아주 자세히

설명되어 있습니다. DAO 를 사용하여 중요한 서버 응용 프로그램을 작성하는 사람들을 위한

필독서입니다.

Lambert, Colleen. ODBC: Architecture, Performance, and Tuning.

여기에서는 ODBC 의 동작 원리와 성능 문제를 파악하는 방법에 대해 실제적이고 유용한 형식으로

다루고 있습니다.

결론

MFC 가 복잡한 기술에 대해 고수준 추상화를 제공한다는 기본 개념이 이 데이터베이스 클래스에서

실현되었습니다. ODBC 와 DAO 중에서 클라이언트에서 최적의 성능을 나타내는 것을 선택할 수

있습니다.

성능을 개선하는 방법을 조사하는 데 많은 시간을 할애했고 다양한 데이터 원본에서 클래스를 실행하는

방법에 대해 공부했으며 그 밖에 많은 연구 과제들을 제시했습니다. 무슨 작업을 하든지 항상 결정하기

전에 프로토타입을 설계하십시오. 오늘 배운 내용들이 여러분의 결정을 도와 줄 수 있기를 희망합니다.