어떤 데이터베이스 제약(constraint)들이 있나요?

Question

IT Interview Practice · Accepted Answer

**제약(constraint)**은 테이블의 데이터에 대해 데이터베이스가 강제하는 규칙입니다 — 애플리케이션 코드뿐 아니라 데이터베이스 수준에서 데이터 무결성을 보장합니다. 주요 제약: `PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE`, `NOT NULL`, `CHECK`, `DEFAULT`.

## 주요 제약

```sql
CREATE TABLE users (
    id       INT PRIMARY KEY,                    -- unique + not null 식별자
    email    VARCHAR(255) UNIQUE NOT NULL,        -- 유일해야 하고 존재해야 함
    age      INT CHECK (age >= 0 AND age <= 120), -- 조건을 만족해야 함
    country  VARCHAR(2) DEFAULT 'US',             -- 제공되지 않으면 기본값
    role     VARCHAR(20) NOT NULL DEFAULT 'user',
    manager_id INT REFERENCES users(id)           -- FOREIGN KEY (참조 무결성)
);
```

```text
PRIMARY KEY  → 행을 유일하게 식별 (unique + not null, index됨)
FOREIGN KEY  → 다른 테이블의 키 참조 (참조 무결성)
UNIQUE       → 이 컬럼에 중복 값 허용 안 됨
NOT NULL     → 컬럼에 값이 있어야 함 (NULL 불가)
CHECK        → 값이 조건을 만족해야 함 (age >= 0, status IN (...))
DEFAULT      → 삽입 시 값이 제공되지 않으면 사용되는 값
```

## 왜 애플리케이션이 아니라 데이터베이스 수준에서 강제하는가?

```sql
-- ❌ 유일성 강제를 애플리케이션 코드에만 의존:
--    race condition, 버그, 또는 다른 앱이 중복을 삽입할 수 있음

-- ✅ UNIQUE 제약은 DB 수준에서 보장 — 어떤 코드나 몇 개의 앱이
--    데이터베이스에 접근하든 항상 강제됨
email VARCHAR(255) UNIQUE
```

데이터베이스 제약은 데이터 무결성의 **최후의 방어선**입니다 — 어떤 코드가 데이터를 삽입하든(여러 애플리케이션, 스크립트, 수동 변경, 버그 있는 코드) 강제되며, 애플리케이션 수준 검사가 놓치는 race condition을 처리합니다.

## 도메인 규칙을 위한 CHECK 제약

```sql
CHECK (price > 0)                          -- 가격은 양수여야 함
CHECK (status IN ('active', 'inactive'))    -- 유효한 status만
CHECK (end_date > start_date)               -- 논리적 일관성
```

`CHECK`는 비즈니스/도메인 규칙을 스키마에 직접 강제합니다.

## 왜 중요한가

제약은 **데이터 무결성**을 유지하는 데 필수적입니다 — 데이터베이스의 데이터가 규칙(유일성, 존재, 유효한 값, 유효한 참조)을 데이터베이스 수준에서 만족하도록 보장하며, 이는 신뢰할 수 있는 애플리케이션에 근본적이므로, 이해하는 것이 중요합니다.

제약 유형(`PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE`, `NOT NULL`, `CHECK`, `DEFAULT`)과 각각이 강제하는 것을 아는 것은 올바른 스키마 설계에 필요합니다.

가장 중요한 개념적 요점은 **애플리케이션 코드에만이 아니라 데이터베이스 수준에서 강제하는 이유**입니다: 데이터베이스 제약은 데이터 무결성의 **최후의 방어선**입니다 — 어떤 코드나 몇 개의 애플리케이션이 데이터에 접근하든 항상 강제되고, 애플리케이션 검사가 놓칠 수 있는 버그를 잡으며, 결정적으로 애플리케이션 수준 검증이 처리할 수 없는 **race condition**을 처리합니다(예: 두 동시 삽입이 모두 앱 수준 유일성 검사를 통과하지만 `UNIQUE` 제약이 중복을 올바르게 거부).

무결성을 애플리케이션 코드에만 의존하는 것은 위험하며, 제약이 보장을 제공합니다.

**`CHECK` 제약**으로 도메인/비즈니스 규칙(유효한 범위, 허용된 값, 논리적 일관성)을 스키마에 직접 강제하는 것을 이해하는 것도 가치 있습니다.

데이터 무결성은 신뢰할 수 있는 애플리케이션에 결정적이고, 제약은 애플리케이션 코드만으로는 할 수 없는 방식으로 버그, race condition, 불일치 데이터로부터 보호하는 데이터베이스 수준 보장을 제공하므로, 제약을 이해하는 것 — 유형, 무결성 보장, 데이터베이스 수준 강제의 중요성 — 은 견고한 데이터베이스 설계에 중요하고 기초적인 지식이자 데이터가 일관되고 유효하게 유지되는 애플리케이션 구축의 핵심 측면입니다.

주요 제약

왜 애플리케이션이 아니라 데이터베이스 수준에서 강제하는가?

도메인 규칙을 위한 CHECK 제약

왜 중요한가

관련 질문