5. 자주 하는 실수 (Tip)
실수 1: 제약 조건에 이름을 안 붙여 오류 메시지를 못 읽는다
이름 없이 만든 제약은 CONSTRAINT_179 처럼 알아볼 수 없는 자동 이름이 붙습니다. 오류가 나도 어떤 규칙이 걸렸는지 이름만 봐서는 알 수 없어, 결국 테이블 정의를 다시 열어 확인해야 합니다. 처음부터 pk_·uq_·ck_·fk_ 접두사로 이름을 붙이는 습관이 훨씬 효율적입니다.
실수 2: UNIQUE 의 NULL 허용 개수를 DB 마다 같다고 가정한다
변형 3·6 에서 봤듯이 Oracle·MySQL 과 MSSQL 은 UNIQUE 컬럼의 NULL 허용 개수가 다릅니다. Oracle·MySQL 기준으로 짠 로직을 그대로 MSSQL 에 옮기면, 원래는 통과하던 두 번째 NULL 이 MSSQL 에서만 거부되는 배포 사고로 이어질 수 있습니다.
실수 3: CHECK 만 믿고 애플리케이션 검증을 생략한다
CHECK 는 DB 버전이나 설정에 따라 동작이 갈릴 수 있는 제약입니다. 변형 7 처럼 오래된 MySQL 은 CHECK 를 무시했고, 지금도 일부 레거시 환경에는 이런 버전이 남아 있습니다. 값 검증은 CHECK 와 애플리케이션 코드 양쪽에 이중으로 두는 편이 안전합니다.
실수 4: FK 의 ON DELETE 옵션을 정하지 않고 CASCADE 라고 착각한다
ON DELETE 절을 아예 안 쓰면 기본 동작은 CASCADE 가 아니라 "자식이 남아 있으면 부모 삭제를 거부"하는 쪽입니다. 변형 4 의 p2·c2 처럼 삭제가 막혀야 정상인데, CASCADE 로 자동 삭제될 거라 예상하고 있다가 삭제 자체가 실패하는 오류를 처음 마주치면 당황하기 쉽습니다. 부모-자식을 함께 지우고 싶다면 CASCADE 를 명시적으로 적어야 합니다.