2. 테이블 네이밍 규칙

2-1. prefix / postfix 금지

tb_, _tbl 같은 타입 표시용 접두·접미사는 쓰지 않는다.
단, 마스터 테이블의 하위 속성 테이블을 묶는 목적의 prefix 는 허용한다.

Bad	Good	설명
`tb_user`	`member`	불필요한 prefix 제거
`user_tbl`	`member`	불필요한 postfix 제거
—	`member_auth`	마스터(`member`) 하위 속성
—	`book_like`	마스터(`book`) 하위 속성

2-2. 단수형 사용 (+ 예약어 예외)

테이블 이름은 단수형으로 쓴다. 엔티티 1건이 1행이라는 읽기 방식과 member_id PK 컨벤션에 정합한다.

이것은 팀 컨벤션이다. 엔진 문서와 표준 SQL 에는 테이블명의 수(數)에 관한 규정이 없고, 널리 쓰이는 공개 SQL 스타일 가이드는 오히려 집합명사 또는 복수형을 권한다. 단수형의 실익은 조인 테이블(2-3)과 FK 컬럼(3-1) 이름이 기계적으로 유도된다는 점이고, 어느 쪽을 고르든 한 스키마 안에서 섞지 않는 것이 규칙의 본질이다.

WARNING — 예약어 충돌 시 예외

단수형 이름이 예약어와 충돌하면(예: user 는 PostgreSQL 예약어) 따옴표로 감싸지 말고 이름 자체를 바꾼다. 권장: user → member, order → purchase_order 또는 order_info, group → user_group.

2-3. 다대다(M:N) 조인 테이블

두 마스터를 잇는 조인 테이블은 <테이블A>_<테이블B> 형식으로 하고, 알파벳 순서로 붙여 팀 내 중복 생성을 방지한다.
의미가 뚜렷한 관계면 도메인 이름을 우선한다. (예: book_like, member_role)

관계	Good
`book` × `tag`	`book_tag`
`member` × `role`	`member_role`

2-4. ENUM 대신 룩업(코드) 테이블

값 목록이 바뀔 수 있는 분류 컬럼은 ENUM 대신 룩업 테이블 + FK 로 만든다. 룩업 테이블은 <도메인>_code 또는 <도메인>_type 형태로 짓는다. (예: order_status_code)

MySQL 문서로 확인되는 ENUM 의 제약이 근거다.

정렬이 선언 순서를 따른다. ENUM 값은 내부 인덱스 번호로 정렬되고 그 번호는 컬럼 스펙에 열거한 순서에서 나온다. ENUM('b', 'a') 에서는 'b' 가 'a' 보다 먼저 온다. 빈 문자열은 비어 있지 않은 문자열보다, NULL 은 모든 열거값보다 앞이다. 사전 순으로 정렬하려면 알파벳 순으로 선언하거나 ORDER BY CAST(col AS CHAR) 처럼 캐스팅해야 한다.
값 목록이 컬럼 정의에 고정된다. ENUM 은 테이블을 만드는 시점에 컬럼 스펙에 명시적으로 열거된 목록에서 값을 고르는 문자열 객체다.
값 목록을 관계형으로 조회할 수 없다. 가능한 값 전체를 알려면 SHOW COLUMNS FROM tbl_name LIKE 'enum_col' 출력의 Type 컬럼에 담긴 ENUM 정의를 파싱해야 한다.
숫자형 값은 MySQL 이 직접 만류한다. TINYINT·SMALLINT 대비 저장 이점이 없고 문자열과 내부 번호를 혼동하기 쉽다 — ENUM('0','1','2') 컬럼에 2 를 넣으면 두 번째 값인 '1' 이 저장된다.
값에 표현식과 변수를 쓸 수 없다. CONCAT('med','ium') 같은 식이나 사용자 변수로 열거값을 정의할 수 없다.
strict 모드가 아니면 잘못된 값이 빈 문자열로 들어간다. 특별한 에러 값으로 빈 문자열이 저장된다. strict SQL 모드에서는 에러다. 정의에 중복 값이 있으면 경고가, strict 모드에서는 에러가 난다.

값 목록이 진짜로 고정이고 정렬을 선언 순서에 맡겨도 되는 컬럼에는 ENUM 을 써도 된다. 한 컬럼의 최대 멤버 수는 65,535 다.

2-5. 약어 사용 제한

되도록 약어를 피하고, 부득이한 경우 소문자로 쓰며 약어 정의서(6장) 에 등재해 팀에 전파한다.

Bad	Good
`create_dt`	`created_date`
`user_cd`	`member_code`