논리적 모델링에서 정의한 한글 엔티티·속성을 이제 실제 DB의 테이블과 컬럼으로 옮기는 단계에서는, 아무렇게나 이름을 짓지 않는다. 프로젝트 전체에 걸쳐 일관된 규칙을 정하고 모두가 그 규칙을 따른다.

이 규칙을 보통 **명명 규칙(Naming Convention)**이라고 부른다. 잘 정리된 명명 규칙은 그 자체로 강력한 문서 역할을 한다.

2-1. 절대적인 규칙은 없다, 하지만 일관성은 필수다

• 프로젝트마다, 조직마다 어울리는 규칙이 다를 수 있다.
• 어떤 규칙이 더 낫다고 단정짓기보다는 장단점을 이해하고 선택하는 것이 중요하다.
• 한 번 결정한 규칙은 데이터베이스 전체에 일관성 있게 적용해야 한다.

2-2. 일반적인 명명 규칙

실무에서 자주 사용하는 기본 규칙을 정리하면 다음과 같다.

1. 영어 사용
   • 테이블, 컬럼, 인덱스 이름은 가급적 영어를 사용한다.
   • 한글 이름은 일부 도구나 라이브러리와의 호환성 문제를 유발할 수 있다.
2. 소문자 + 스네이크 케이스(snake_case)
   • 모든 이름은 소문자로 작성하고, 여러 단어는 언더스코어(_)로 연결한다.
   • 예: member, order_item, created_at
   • 운영체제에 따라 대소문자를 다르게 처리하는 경우가 있기 때문에, 소문자로 통일하는 편이 안전하다.
3. 명확하고 서술적인 이름
   • 이름만 보더라도 이 컬럼이 무엇을 의미하는지 알 수 있어야 한다.
   • 의미가 불분명한 축약은 피한다.
   • 예: member_registration_datetime은 mem_reg_dt보다 훨씬 명확하다.
   • 다만 mem, reg, dt를 팀에서 표준 축약어로 정했다면 mem_reg_dt처럼 사용하는 것도 가능하다.
4. 일관된 접두사·접미사 사용
   • PK, 날짜/시간, 불리언 등 특정 역할을 하는 컬럼에는 일관된 네이밍 패턴을 부여한다.
5. 예약어 사용 금지
   • ORDER, GROUP, SELECT, CREATE 등 SQL 예약어는 테이블·컬럼 이름으로 사용하지 않는다.
   • 예: 주문 테이블은 order 대신 orders로 만든다.

2-3. 컬럼 이름 규칙

2-3-1. PK는 테이블명_id 형식으로

모든 테이블의 PK를 단순히 id라고 지으면, 여러 테이블을 조인했을 때 어느 테이블의 id인지 알기 어려운 문제가 발생한다.

-- member와 orders 테이블의 PK가 모두 id인 경우 (나쁜 예시)
SELECT
  id,          -- 이 id가 어느 테이블의 id인지 모호하다
  member_name,
  ordered_at
FROM member
JOIN orders ON member.id = orders.member_id;

위 쿼리는 Column 'id' in field list is ambiguous 오류가 발생하거나, 매번 member.id, orders.id처럼 테이블 이름/별칭을 붙여야 한다.

반면, PK를 member_id, order_id처럼 테이블명을 포함해서 짓는 경우를 보자.

-- PK를 테이블명_id로 정의한 경우 (권장 예시)
SELECT
  m.member_id,
  o.order_id,
  m.member_name,
  o.ordered_at
FROM member m
JOIN orders o ON m.member_id = o.member_id;