앱 검증과 별개로 핵심 컬럼에는 NOT NULL을 둔다.
DESIGN PRINCIPLES
제약 조건은 데이터 품질을 스키마에 고정하는 장치다
제약을 줄이면 당장은 편해 보이지만 잘못된 데이터가 들어간 뒤의 복구 비용이 커진다. 업무 규칙은 가능한 한 DB 단계에도 남긴다.
이메일, 주문번호처럼 하나여야 하는 값은 UNIQUE로 보장한다.
없는 부모를 참조하는 고아 데이터를 만들지 않는다.
상태값, 금액, 날짜 순서처럼 행 내부 규칙을 선언한다.
| 상황 | 권장 제약 | 피할 점 |
|---|---|---|
| 로그인 식별자 | NN + UQ |
앱에서만 중복 검사 |
| 주문과 회원 관계 | FK |
회원이 없는 주문 허용 |
| 상태 코드 | CHECK 또는 코드 테이블 FK |
임의 문자열 저장 |
| 대량 적재 | 검증 쿼리 후 제약 활성화 | 제약을 영구 비활성화 |
기준: 성능 때문에 제약을 없애야 한다면, 대체 검증과 복구 책임까지 함께 설계해야 한다.