확인 제약조건 만들기 및 관리

CHECK 제약 조건을 사용하면 열 하나 이상의 값이 불리언 표현식을 충족해야 하도록 지정할 수 있습니다. 이 페이지에서는 GoogleSQL 언어 데이터베이스와 PostgreSQL 언어 데이터베이스에서 이 유형의 제약조건을 추가하고 관리하는 방법을 설명합니다.

새 테이블에 확인 제약조건 추가

다음 CREATE TABLE 스니펫에서 연주회 관련 정보를 저장하기 위한 테이블을 만듭니다. 연주회의 종료 시간이 시작 시간보다 이후에 오도록 확인 제약조건을 포함합니다.

GoogleSQL 

CREATE TABLE Concerts (
  ConcertId INT64,
  StartTime Timestamp,
  EndTime Timestamp,
  CONSTRAINT start_before_end CHECK(StartTime < EndTime),
) PRIMARY KEY (ConcertId);

PostgreSQL 

CREATE TABLE Concerts (
  ConcertId BIGINT,
  StartTime TIMESTAMPTZ,
  EndTime TIMESTAMPTZ,
  CONSTRAINT start_before_end CHECK(StartTime < EndTime),
  PRIMARY KEY (ConcertId)
);

제약조건 정의는 CONSTRAINT 키워드로 시작합니다. 이 예시에서는 오류 메시지에서 찾고 필요할 때마다 참조하는 데 도움이 되도록 제약 조건 이름을 명시적으로 start_before_end로 지정했습니다. 이름을 지정하지 않으면 Spanner에서 CK_ 프리픽스로 시작하는 생성된 이름의 제약 조건을 제공합니다. 제약 조건 이름은 테이블과 색인의 이름을 통해 스키마로 범위가 제한되며 스키마 내에서 고유해야 합니다. 확인 제약 조건 정의는 CHECK 키워드와 괄호로 묶인 표현식으로 구성됩니다. 표현식은 이 테이블의 열만 참조할 수 있습니다. 이 예시에서는 StartTime 및 EndTime을 참조하고 확인 제약 조건에서 연주회 시작 시간이 항상 종료 시간보다 이전인지 확인합니다.

확인 제약 조건 표현식 값은 새 행이 삽입될 때 또는 기존 행의 StartTime 또는 EndTime이 업데이트될 때 평가됩니다. 표현식이 TRUE 또는 NULL로 평가될 경우 확인 제약조건에서 데이터 변경이 허용됩니다. 표현식이 FALSE로 평가되면 데이터 변경이 허용되지 않습니다.

  • 다음 제약조건이 확인 제약조건 expression 항에 적용됩니다.

    • 이 표현식은 동일 테이블의 열만 참조할 수 있습니다.

    • 표현식은 직접 또는 비생성 열을 참조하는 생성 열을 통해 하나 이상의 비생성 열을 참조해야 합니다.

    • 표현식은 allow_commit_timestamp 옵션이 설정된 열을 참조할 수 없습니다.

    • 표현식은 서브 쿼리를 포함할 수 없습니다.

    • 표현식은 CURRENT_DATE() 및 CURRENT_TIMESTAMP()와 같은 비결정적 함수를 포함할 수 없습니다.

기존 테이블에 확인 제약조건 추가

다음 ALTER TABLE 문을 사용하여 모든 연주회 ID가 0보다 큰지 확인하는 제약조건을 추가합니다.

ALTER TABLE Concerts
ADD CONSTRAINT concert_id_gt_0 CHECK (ConcertId > 0);

다시 한 번 제약조건에 concert_id_gt_0 이름을 지정했습니다. 기존 테이블에 CHECK 제약조건을 추가하면 새 데이터에 대해 즉시 제약조건이 적용되고 기존 데이터가 새 제약조건을 준수하는지 확인하는 장기 실행 작업이 시작됩니다. 이러한 검사가 장기 실행 작업으로 수행되기 때문에 테이블에서 진행 중인 트랜잭션은 영향을 받지 않습니다. 자세한 내용은 스키마 업데이트 성능을 참조하세요. 기존 데이터에 위반 사항이 있으면 제약조건이 롤백됩니다.

확인 제약조건 삭제

다음 DDL 문은 Concerts 테이블에서 CHECK 제약 조건을 삭제합니다.

ALTER TABLE Concerts
DROP CONSTRAINT concert_id_gt_0;

확인 제약조건 표현식 수정

CHECK 제약조건의 표현식 수정은 허용되지 않습니다. 대신 새 표현식으로 기존 제약조건을 삭제하고 새 제약조건을 생성해야 합니다.

확인 제약조건의 속성 보기

Spanner의 INFORMATION_SCHEMA에는 데이터베이스의 확인 제약 조건에 대한 정보가 포함되어 있습니다. 다음은 정보 스키마를 쿼리하여 답변할 수 있는 몇 가지 질문의 예시입니다.

내 데이터베이스에 어떤 확인 제약조건이 정의 되어 있나요?

SELECT tc.CONSTRAINT_NAME, tc.TABLE_NAME, tc.CONSTRAINT_TYPE
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS as tc
WHERE tc.CONSTRAINT_TYPE = 'CHECK';

내 데이터베이스에서 확인 제약조건의 현재 상태는 무엇인가요?

기존 테이블에 확인 제약조건을 추가한 경우, 모든 기존 데이터가 제약조건에 대해 검증되었는지 여부와 같이 현재 상태를 확인해야 할 수 있습니다. SPANNER_STATE가 다음 쿼리로 VALIDATING_DATA를 반환하는 경우 이는 Spanner가 해당 제약 조건에 대해 기존 데이터를 계속 검증하고 있음을 나타냅니다.

SELECT cc.CONSTRAINT_NAME, cc.SPANNER_STATE
FROM INFORMATION_SCHEMA.CHECK_CONSTRAINTS as cc;

다음 단계