Primary Key: 모든 행에 정체성

행의 영구 정체성

Primary key 는 행의 영구 이름 — 테이블 안 유일, NULL 절대 없음, 이상적으론 절대 안 바뀜. 이게 없으면 다른 테이블에서, 앱에서, 새벽 2 시 디버깅하는 미래의 자기에서 행을 신뢰성 있게 가리킬 수 없어. 모든 테이블이 가져야 함. 예외 없음.

좋은 PK 가 되는 조건

유일. 두 행이 값을 공유 안 함.
NULL 아님. 모든 행이 가짐.
불변. 행 만든 후 절대 안 바뀜.
compact + 인덱싱 가능. Integer 또는 UUID — 비즈니스 필드 200 자 합성 아님.

Surrogate vs natural key

Natural key = 실세계 데이터 (email, ISBN, phone). Surrogate key = 비즈니스 의미 0 인 시스템 생성값 (auto-increment integer, UUID). Surrogate 선호; email 같은 natural 필드는 UNIQUE 제약으로 유지. 실세계 식별자는 실제로 바뀌고 (사람이 email 바꾸고, ISBN 재발행), PK 바뀌면 모든 FK 참조에 cascade 고통.

Composite primary key

순수 junction 테이블 (many-to-many bridge) 에선 두 FK 의 composite key 가 자연스러운 핏이고 redundant surrogate 컬럼 안 만들어도 됨.

Code

Surrogate PK (권장 default)·sql

CREATE TABLE users (
    id    INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email TEXT UNIQUE NOT NULL,
    name  TEXT NOT NULL
);

Junction 테이블의 composite PK·sql

CREATE TABLE course_enrollments (
    student_id INTEGER NOT NULL REFERENCES students(id) ON DELETE CASCADE,
    course_id  INTEGER NOT NULL REFERENCES courses(id)  ON DELETE CASCADE,
    enrolled   DATE NOT NULL DEFAULT CURRENT_DATE,
    PRIMARY KEY (student_id, course_id)
);

공개 ID 를 위한 UUID PK·sql

CREATE TABLE api_tokens (
    id         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Primary Key: 모든 행에 정체성

행의 영구 정체성

좋은 PK 가 되는 조건

Surrogate vs natural key

Composite primary key

Code

External links

Exercise

Progress

댓글 0