데이터베이스 오류 처리

대부분의 데이터베이스 오류는 연결 오류이며 어떠한 작업 중에도 발생할 수 있습니다. 연결 오류를 방지하기 위한 전략이 있지만 데이터베이스가 응용 프로그램의 필수적 부분인 경우 연결 오류에서 적절하게 복구하는 간단한 방법은 거의 없습니다.

대부분의 연결 오류는 런타임에서 운영 체제, 파일 시스템 및 데이터베이스 파일과 상호 작용하는 방식과 관련이 있습니다. 예를 들어, 사용자가 파일 시스템의 특정 위치에서 데이터베이스를 만들 수 있는 권한이 없으면 연결 오류가 발생합니다. 다음 전략은 연결 오류를 방지하는 데 도움이 됩니다.

사용자별 데이터베이스 파일 사용

한 컴퓨터에서 응용 프로그램을 사용하는 모든 사용자에 대해 하나의 데이터베이스 파일을 사용하지 말고 각 사용자에게 개별 데이터베이스 파일을 제공합니다. 데이터베이스 파일은 사용자의 계정과 연결된 디렉토리에 있어야 합니다. 예를 들어, 데이터베이스 파일은 응용 프로그램의 저장소 디렉토리, 사용자의 문서 폴더, 사용자의 바탕 화면 등에 있을 수 있습니다.

여러 사용자 유형 고려

서로 다른 운영 체제에서 여러 유형의 사용자 계정을 사용하여 응용 프로그램을 테스트합니다. 사용자가 컴퓨터에서 관리자 권한이 있다고 가정하지 마십시오. 또한 응용 프로그램을 설치한 개인이 응용 프로그램을 실행하고 있는 사용자라고 가정하지도 마십시오.

다양한 파일 위치 고려

사용자가 데이터베이스 파일을 저장할 위치를 지정하거나 열 파일을 선택할 수 있게 하려면 사용자가 사용할 수 있는 가능한 파일 위치를 고려합니다. 또한 사용자가 데이터베이스 파일을 저장할 수 있거나 열 수 있는 위치에 대한 제한을 정의하는 것을 고려합니다. 예를 들어, 사용자가 사용자 계정의 저장소 위치에 있는 파일만 열 수 있게 할 수도 있습니다.

연결 오류는 처음으로 데이터베이스를 만들거나 열려고 할 때 발생할 가능성이 가장 큽니다. 따라서 사용자가 응용 프로그램에서 데이터베이스 관련 작업을 수행할 수 없습니다. 읽기 전용 또는 권한 오류와 같은 특정 유형의 오류에 대한 한 가지 가능한 복구 방법은 데이터베이스 파일을 다른 위치에 복사하는 것입니다. 응용 프로그램에서는 사용자가 파일을 만들고 파일에 쓸 수 있는 권한이 있는 다른 위치에 데이터베이스 파일을 복사하고 해당 위치를 대신 사용할 수 있습니다.

구문 오류는 SQL 문의 형식이 잘못되고 응용 프로그램에서 SQL 문을 실행하려고 할 때 발생합니다. 로컬 데이터베이스 SQL 문이 문자열로 만들어지기 때문에 컴파일 타임 SQL 구문 검사를 수행할 수 없습니다. 모든 SQL 문은 구문을 검사하기 위해 실행되어야 합니다. SQL 구문 오류를 방지하려면 다음 전략을 사용하십시오.

모든 SQL 문을 완전히 테스트합니다.

가능한 경우 응용 프로그램을 개발하는 동안 SQL 문을 응용 프로그램 코드에서 문 텍스트로 인코딩하기 전에 별도로 테스트합니다. 또한 단위 테스트와 같은 코드 테스트 방법을 사용하여 코드에서 가능한 모든 옵션과 변형을 실행하는 테스트 집합을 만듭니다.

문 매개 변수를 사용하고 SQL 연결(동적 생성)을 피합니다.

매개 변수를 사용하고 동적으로 만들어진 SQL 문을 방지하는 것은 동일한 SQL 문 텍스트가 문이 실행될 때마다 사용된다는 의미입니다. 따라서 문을 테스트하고 가능한 변형을 제한하기가 훨씬 쉽습니다. SQL 문을 동적으로 생성해야 하는 경우 문의 동적 부분을 최소로 유지합니다. 또한 사용자 입력의 유효성을 신중하게 검사하여 구문 오류를 발생시키지 않게 합니다.

구문 오류에서 복구하려면 SQL 문을 검사하고 구문을 수정할 수 있는 복잡한 논리가 응용 프로그램에 필요합니다. 구문 오류 방지를 위한 위의 지침을 따르면 코드에서 SQL 구문 오류의 가능한 런타임 원인(예: 문에서 사용되는 사용자 입력)을 식별할 수 있습니다. 구문 오류에서 복구하려면 사용자에게 지침을 제공하고 문이 제대로 실행되게 하기 위해 수정할 것을 나타냅니다.

제약 조건 오류는 INSERT 또는 UPDATE 문에서 데이터를 열에 추가하려고 할 때 발생합니다. 새 데이터가 테이블이나 열에 대해 정의된 제약 조건 중 하나를 위반하면 이 오류가 발생합니다. 가능한 제약 조건의 집합은 다음과 같습니다.

UNIQUE 제약 조건

테이블의 모든 행에서 한 열에 중복 값이 있을 수 없도록 지정합니다. 또한 UNIQUE 제약 조건에서 여러 열이 결합된 경우 해당 열의 값 조합은 중복되지 않아야 합니다. 즉, 지정된 고유 열 측면에서 각 행은 고유해야 합니다.

PRIMARY KEY 제약 조건

제약 조건이 허용하고 허용하지 않는 데이터의 측면에서 PRIMARY KEY 제약 조건은 UNIQUE 제약 조건과 동일합니다.

NOT NULL 제약 조건

한 열에 NULL 값이 저장될 수 없고 이에 따라 모든 행에서 해당 열에는 값이 있어야 하도록 지정합니다.

CHECK 제약 조건

하나 이상의 테이블에 대한 임의의 제약 조건을 지정할 수 있습니다. 일반적인 CHECK 제약 조건은 열의 값이 특정 범위 안에 들어야 하도록(예를 들어, 숫자 열의 값이 0보다 커야 하도록) 정의하는 규칙입니다. CHECK 제약 조건의 또 다른 일반적 유형은 열 값 간의 관계를 지정합니다. 예를 들어, 열의 값이 동일한 행에 있는 다른 열의 값과 달라야 하도록 지정할 수 있습니다.

DATA TYPE(열 선호도) 제약 조건

런타임은 열 값의 데이터 유형을 적용하며 잘못된 유형의 값을 열에 저장하려고 하면 오류가 발생합니다. 그러나 많은 조건에서 값이 열의 선언된 데이터 유형과 일치하도록 변환됩니다. 자세한 내용은 데이터베이스 데이터 유형 작업 을 참조하십시오.

런타임은 외래 키 값에 제약 조건을 적용하지 않습니다. 즉, 외래 키 값이 기존 기본 키 값과 일치할 필요가 없습니다.

런타임 SQL 엔진은 미리 정의된 제약 조건 유형 외에도 트리거 사용을 지원합니다. 트리거는 이벤트 핸들러와 유사하며 특정 작업이 발생할 때 수행되는 미리 정의된 명령의 집합입니다. 예를 들어, 데이터가 특정 테이블에서 삽입되거나 삭제될 때 실행되는 트리거를 정의할 수 있습니다. 데이터 변경 사항을 검사하고 지정된 조건이 충족되지 않으면 오류가 발생하게 하려는 경우 등에 트리거를 사용할 수 있습니다. 따라서 트리거는 제약 조건과 동일한 용도로 사용할 수 있으며 제약 조건 오류를 방지하고 제약 조건 오류에서 복구하기 위한 전략이 트리거에서 생성된 오류에도 적용됩니다. 그러나 트리거에서 생성된 오류의 ID는 제약 조건 오류의 ID와 다릅니다.

특정 테이블에 적용되는 제약 조건의 집합은 응용 프로그램을 설계하는 동안 결정됩니다. 제약 조건을 의식적으로 설계하면 제약 조건 오류를 방지하고 제약 조건 오류에서 복구하도록 응용 프로그램을 설계하기가 쉬워집니다. 그러나 제약 조건 오류는 체계적으로 예측하고 방지하기가 어렵습니다. 제약 조건 오류는 응용 프로그램 데이터가 추가될 때까지 나타나지 않기 때문에 예측이 어렵습니다. 제약 조건 오류는 데이터가 만들어진 후 데이터베이스에 추가될 때 발생합니다. 이러한 오류는 새 데이터와 데이터베이스에 이미 있는 데이터 간 관계의 결과인 경우가 많습니다. 다음 전략은 많은 제약 조건 오류를 방지하는 데 도움이 될 수 있습니다.

신중하게 데이터베이스 구조 및 제약 조건 계획 수립

제약 조건의 목적은 응용 프로그램 규칙을 적용하고 데이터베이스 데이터의 무결성을 보호하는 것입니다. 응용 프로그램에 대한 계획을 수립할 때 응용 프로그램을 지원할 데이터베이스의 구조를 고려합니다. 이 과정에서 특정 값이 필요한지 여부, 기본값이 있는지 여부, 중복 값이 허용되는지 여부 등의 데이터에 대한 규칙을 확인합니다. 이러한 규칙은 데이터베이스 제약 조건을 정의하는 지침이 됩니다.

명시적으로 열 이름 지정

값을 삽입할 열을 명시적으로 지정하지 않고 INSERT 문을 쓸 수 있지만 이렇게 하면 불필요한 위험이 초래됩니다. 값을 삽입할 열의 이름을 명시적으로 지정하면 자동으로 생성되는 값, 기본값이 있는 열 및 NULL 값을 허용하는 열을 허용할 수 있습니다. 또한 이렇게 하면 모든 NOT NULL 열에 명시적 값이 삽입되게 할 수 있습니다.

기본값 사용

열에 대해 NOT NULL 제약 조건을 지정하는 경우 가능하면 항상 열 정의에 기본값을 지정합니다. 응용 프로그램 코드에서도 기본값을 제공할 수 있습니다. 예를 들어, 코드에서 String 변수가 null 인지 확인하고 이 변수를 사용하여 문 매개 변수 값을 설정하기 전에 이 변수에 값을 할당할 수 있습니다.

사용자가 입력한 데이터의 유효성 검사

사용자가 정의한 데이터를 미리 검사하여 제약 조건(특히 NOT NULL 및 CHECK 제약 조건의 경우)으로 지정된 제한을 준수하는지 확인합니다. UNIQUE 제약 조건의 경우 SELECT 쿼리를 실행하여 데이터가 고유한지 확인해야 하기 때문에 이러한 확인이 더 어렵습니다.

트리거 사용

삽입된 데이터의 유효성을 검사하거나(대체할 수도 있음) 잘못된 데이터를 수정하기 위해 다른 작업을 수행하는 트리거를 작성할 수 있습니다. 이 유효성 검사와 수정을 통해 제약 조건 오류를 방지할 수 있습니다.

다양한 측면에서 제약 조건 오류는 다른 유형의 오류보다 방지하기가 더 어렵습니다. 다행히도 응용 프로그램을 불안정하거나 사용할 수 없게 만들지 않는 방식으로 제약 조건 오류에서 복구하는 몇 가지 전략이 있습니다.

충돌 알고리즘 사용

열에 대한 제약 조건을 정의하는 경우와 INSERT 또는 UPDATE 문을 만드는 경우 충돌 알고리즘을 지정할 수 있습니다. 충돌 알고리즘은 제약 조건 위반이 발생할 때 데이터베이스에서 수행하는 작업을 정의합니다. 데이터베이스 엔진에서 수행할 수 있는 몇 가지 가능한 작업이 있습니다. 데이터베이스 엔진은 한 문이나 전체 트랜잭션을 끝낼 수 있습니다. 또한 오류를 무시할 수 있으며 이전 데이터를 제거하고 코드에서 저장하려는 데이터로 바꿀 수도 있습니다.

자세한 내용은 로컬 데이터베이스의 SQL 지원 에서 "ON CONFLICT(충돌 알고리즘)" 단원을 참조하십시오.

수정 피드백 제공

특정 SQL 명령에 영향을 미칠 수 있는 제약 조건의 집합을 미리 확인할 수 있습니다. 따라서 문에서 발생할 수 있는 제약 조건 오류를 예측할 수 있으며, 이 지식을 사용하여 제약 조건 오류에 응답하는 응용 프로그램 논리를 만들 수 있습니다. 예를 들어, 응용 프로그램에 새 제품을 입력하기 위한 데이터 항목이 포함되어 있는 경우 데이터베이스의 제품 이름 열이 UNIQUE 제약 조건으로 정의되면 데이터베이스에서 새 제품 행을 삽입하는 작업으로 인해 제약 조건 오류가 발생할 수 있습니다. 따라서 응용 프로그램이 제약 조건 오류를 예측하도록 설계됩니다. 오류가 발생하면 응용 프로그램에서 지정된 제품 이름이 이미 사용 중임을 알리고 다른 이름을 선택하도록 요구하는 경고를 사용자에게 표시합니다. 사용자가 동일한 이름의 다른 제품에 대한 정보를 볼 수 있게 할 수도 있습니다.