CHECK 제약 조건

요약

NOT NULL 요구 사항 이상의 데이터 무결성 규칙을 적용하려면 CHECK 제약 조건을 사용하세요. 제약 조건을 만족하는 기본값과 함께 CHECK 제약 조건이 있는 새 칼럼을 추가할 때, 초기 마이그레이션에서 제약 조건 유효성 검사를 건너뛸 수 있습니다.

NOT NULL 요구 사항 이상의 데이터 무결성 규칙을 적용하려면 CHECK 제약 조건을 사용하세요. NOT NULL 제약 조건에 대해서는 NOT NULL 제약 조건을 참조하세요.

기본값이 있는 새 칼럼에 CHECK 제약 조건 추가#

제약 조건을 만족하는 기본값과 함께 CHECK 제약 조건이 있는 새 칼럼을 추가할 때, 초기 마이그레이션에서 제약 조건 유효성 검사를 건너뛸 수 있습니다. 대신 배포 후 마이그레이션(post-deployment migration)에서 제약 조건의 유효성을 검사하세요.

이 방법은 대형 테이블에서 전체 테이블 스캔을 피할 수 있습니다. 그 이유는 다음과 같습니다:

기존 행은 PostgreSQL의 fast defaults 메커니즘을 통해 기본값으로 처리되므로 제약 조건이 이미 만족됩니다.
NOT VALID 제약 조건은 새로운 삽입 및 업데이트에는 여전히 적용되므로 이후 행은 제약 조건을 위반할 수 없습니다.

이 패턴은 기본값 표현식 자체가 제약 조건을 만족하는 경우에만 적용됩니다. 예를 들어, 'active'와 같은 리터럴 문자열 값은 안전하지만, 잘못된 값을 생성할 수 있는 함수 호출이나 표현식에는 이 패턴을 사용하지 않아야 합니다.

제약 조건 및 기본값이 있는 칼럼 추가#

validate: false로 CHECK 제약 조건과 함께 칼럼을 추가하는 일반 마이그레이션을 생성합니다:

class AddStatusCheckToProjects < Gitlab::Database::Migration[2.1]
  def change
    add_column :projects, :status, :string, default: 'active'
    add_check_constraint :projects, "status IN ('active', 'inactive')", name: 'check_status_valid', validate: false
  end
end

제약 조건 유효성 검사#

칼럼을 추가한 후, 동일한 릴리즈의 배포 후 마이그레이션에서 제약 조건의 유효성을 검사합니다. 배포 후 마이그레이션에 대한 자세한 내용은 마이그레이션 스타일 가이드를 참조하세요:

class ValidateProjectsStatusCheckConstraint < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!

  def up
    validate_check_constraint :projects, name: 'check_status_valid'
  end

  def down
    # no-op
  end
end

CHECK 제약 조건

GitLab v19.1

원문 보기

번역일: 2026-06-19

요약