제약 조건 설계 원칙

좋은 제약 설계는 입력을 막고, 변경 전에 위험을 확인합니다.

제약 조건은 데이터 품질의 마지막 방어선입니다. 애플리케이션 검증과 함께 두되, 어떤 경로로 데이터가 들어와도 DB가 최소 규칙을 지키게 만들어야 합니다.

처음 만들 때

허용할 데이터 상태를 좁힌다

식별

대리키는 PK, 업무 값은 UNIQUE

이메일처럼 바뀔 수 있는 값은 식별자보다 유일성 규칙으로 관리합니다.

값

필수값은 NOT NULL, 범위는 CHECK

NULL은 NOT NULL로 막고, 음수 가격이나 잘못된 상태값은 CHECK로 차단합니다.

관계

부모-자식 관계는 FK로 보장

직접 SQL, 배치, 버그가 있어도 부모 없는 자식 행을 남기지 않습니다.

운영 중 바꿀 때

기존 데이터와 파급 효과를 먼저 본다

검사

제약 추가 전 위반 데이터를 찾기

NULL, 중복, 고아 FK가 남아 있으면 ALTER 단계에서 바로 실패합니다.

삭제

CASCADE는 생명주기가 같을 때만

한 번의 삭제가 여러 테이블로 번지므로 기본은 보수적으로 시작합니다.

이름

제약 이름을 명시해 실패 원인을 남기기

로그에 깨진 규칙이 드러나면 수정과 운영 대응이 빨라집니다.

앱 검증만 믿는가? DB 제약이 없으면 직접 SQL이나 배치에서 규칙이 우회될 수 있습니다.
NULL도 막아야 하는가? CHECK만으로는 NULL이 통과할 수 있어, 필수값은 NOT NULL을 함께 둡니다.
삭제가 번지지 않는가? CASCADE는 편하지만 데이터 보존 정책과 감사 요구를 함께 확인합니다.
에러가 읽히는가? 의미 있는 제약 이름은 실패 메시지를 바로 해석 가능한 단서로 만듭니다.