데이터베이스 명명 규칙 (Naming Conventions)

데이터베이스 명명 규칙(Database Naming Conventions)

데이터베이스 설계 작업을 하다보면 어떻게 이름을 명명해야 올바른 네이밍 컨벤션인지 고민하게 된다.

공식적으로 정해진 규칙은 없지만 잘 정리된 글이 해외 사이트에 있어서 나름대로 정리해보려고 한다.(어차피 대부분 기업에서는 기업 내에 컨벤션이 있다고 한다.)

데이터베이스 명명 규칙이 중요한 이유

데이터베이스 구조의 수명은 길다

데이터 구조는 애플리케이션 코드보다 훨씬 오래 지속되는 경우가 많다.

데이터베이스 스키마를 변경하지 않고 새로운 애플리케이션을 개발하는 일은 드물지 않기 때문에 잘 정의된 데이터 구조와 테이블 레이아웃이 중요하다.

데이터베이스 이름은 계약이다.

데이터베이스 개체는 이름으로 참조되므로 개체 이름은 개체에 대한 계약의 일부이다. 어떤 부분에서는 데이터베이스 테이블과 이름을 데이터 모델에 대한 API로 간주할 수 있다.

일단 이름을 짓고난 뒤 변경하면 종속된 응용 프로그램이 중단될 수 있기 때문에 처음에 설계할 때 이름을 올바르게 지정해야 한다.

개발자 편의성

데이터 모델에서 일관된 명명 규칙을 사용하면 개발자가 테이블, 뷰 및 컬럼의 이름을 찾는 데 소비되는 시간을 절약할 수 있다.

Naming Conventions

1. 따옴표를 사용하지 않는다.

• “FirstName” 또는 “All Employees” 등의 이름은 대표적인 나쁜 이름의 예시이다.
• 이름에 따옴표를 사용하면 SQL을 작성하기 어려워진다.
• 또한 이름에 공백을 포함해서는 안된다.

2. 이름은 소문자로 작성해야 한다.

• 이 규칙은 테이블, 뷰, 컬럼 및 기타 모든 것이 포함된다. 대소문자가 혼합된 이름은 사용할 때마다 큰따옴표로 묶어야 함을 의미한다.(1번에 위배됨)

3. 데이터 타입을 이름으로 작성하면 안된다.

• 데이터베이스 객체 이름, 특히 컬럼 이름은 필드 또는 객체를 설명하는 명사여야 한다. text 또는 timestamp 와 같은 데이터 타입의 이름을 사용하면 안된다.

4. 단어 사이는 underscores(_)로 구분한다. (Snake Case)

• 여러 단어로 구성된 객체 이름의 경우 언더스코어로 구분해야 한다.
• ex : wordCount 나 wordcount 대신 word_count를 사용한다.

5. 약어를 사용하지 않는다.

• 객체 이름은 완전한 영어 단어로 작성해야 한다.
• 대부분의 데이터베이스는 최소 30자의 이름을 지원하므로 충분하다.
• ex : mid_nm 대신에 middle_name 사용

6. 전체 단어보다 통용되는 약어는 사용한다.

• 몇 긴 단어의 경우 약어가 단어 자체보다 더 통용되는 경우가 있다. 이런 경우에는 약어를 사용한다.
• ex : Internationalization → i18n , localization → l10n (처음 들어봄;;)

7. 예약어는 피한다.

• 사용중인 데이터베이스에서 예약어로 간주되는 단어는 사용하지 않는다.
• 예약어를 이름에 사용하면 따옴표를 붙여줘야 할 수 있다. (1번 위배)
• ex : user, locak, table 등을 이름으로 사용하지 않는다.

단수 관계

데이터를 보유하는 테이블, 뷰 및 기타 관계는 복수형이 아닌 단수형 이름을 가져야 한다.

예를 들어 팀에 대한 테이블의 경우 teams가 아닌 team으로 이름을 지정해야 한다.

단수로 지정해야 하는 이유는 다음과 같다.

1. 일관성 : 단일 행을 보유하는 관계를 가질 수 있다.
2. 분명하다 : 단수 이름을 사용하면 명사를 복수화하는 방법을 고민할 필요가 없다. (ex : Person의 경우 복수 이름을 사용하면 Persons로 지을지 People로 지을지 결정해야 한다. Octopus 는 Octopuses, Octopi, Octopodes 등)
3. 프로그래밍 언어와 데이터베이스 간 변환이 간단하다. : 단수 이름을 사용하면 프로그래밍 언어와 DB 간의 이름 변환이 간단히 적용된다.

주요 필드

기본 키

• 기본 키 필드의 이름은 id로 작성한다. 짧고 간단하며 모호하지 않다.
• 일부 가이드에서는 기본 키 필드에 테이블 이름을 접두어로 추가할 것을 권장한다. (ex : person_id) 그러나 SQL 문에서 필드 이름은 명시적으로 수식되어야 하므로 네임스페이스 형태로 접두사를 붙이는 것은 좋지 않다.

외래키

• 외래 키 필드는 참조된 테이블의 이름과 참조된 필드의 이름 조합이어야 한다.
• 아래는 team과 person 테이블을 참조한 외래 키 이름의 예시이다.

CREATE TABLE team_member (
	team_id int NOT NULL REFERENCES team(id),
	person_id int NOT NULL REFERENCES person(id)

접두사 및 접미사 (나쁨)

아래 3가지 접두사 또는 접미사 유형은 모두 나쁜 사례이다.

관계 타입 접두사

• 일부 지침에서는 테이블 이름에 “TB_”, 뷰의 이름에 “VW_”와 같은 접두사를 제안한다. 처음보는 SQL을 읽는 프로그래머가 이름을 기반으로 타입을 알 수 있다는 근거인데, 이 것은 나쁜 생각이다.
• 개체 이름에는 개체 유형이 포함되어서는 안된다. 그래야 나중에 개체를 변경하기 수월하다. 뷰가 어느 시점에서 테이블이 되는 경우가 있는데, 접두사를 붙이면 필드명을 변경해야 하므로 변경 후에 종속된 시스템들을 수정해야 한다.

애플리케이션 이름 접두사

• 모든 데이터베이스 객체에 대해 공통 접두사를 사용하는 것이다. 예를 들어 Foobar라는 앱에서 사용하는 테이블 이름 앞에 앱의 이름을 접두사로 사용하는 것이다. (Foobar_users, Foobar_teams) 이 방법은 옳지 않다.
• 모든 최신 데이터베이스는 어떤 형태의 네임스페이스를 지원한다. 예를 들어 PostgreSQL에서 스키마를 생성하여 데이터베이스 객체를 그룹화할 수 있다. 동일한 데이터베이스를 공유하는 여러 애플리케이션이 있고 서로 방해하는 것을 방지하려면 대신 스키마를 사용하면 된다.
• 이 규칙의 예외는 프레임워크나 플러그인과 같은 데이터베이스에 구애받지 않는 코드 기반을 개발하는 경우이다. 그러나 대부분 사람들은 플러그인이나 프레임워크가 아닌 응용 프로그램을 개발하므로 모든 데이터베이스 객체 이름에 접두사를 추가할 이유가 없다.

데이터 타입 접미사

• 일부 가이드(일반적으로 오래된 가이드)에서는 필드의 데이터 타입으로 컬럼 이름에 접미사를 추가할 것을 제안한다. 예를 들어 텍스트 타입의 이름 필드인 경우 name_tx와 같다. 이것은 나쁜 방법이다.
• 필드 데이터 타입은 변경될 수 있다. Date는 TimeStamp가 될 수 있고 int는 bigint 또는 numeric으로 변경될 수 있다.

명시적 이름 지정

데이터베이스 객체를 만드는 일부 데이터베이스 명령은 이름을 지정할 필요가 없다. 객체 이름은 무작위 또는 규칙을 통해 생성된다. 이름이 생성되는 방법을 정확히 알지 못하므로 명시적으로 이름을 지정해야 한다.

인덱스

• 인덱스는 명시적으로 이름을 지정해야 하며 인덱싱된 테이블 이름과 컬럼 이름을 모두 포함해야 한다.
• 자동으로 생성된 foobar_ix1 과 같은 인덱스 이름은 한눈에 이해하기 어렵다.

CREATE TABLE person (
  id          bigserial PRIMARY KEY,
  email       text NOT NULL,
  first_name  text NOT NULL,
  last_name   text NOT NULL,
  CONSTRAINT person_ck_email_lower_case CHECK (email = LOWER(email)));

CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);

위와 같이 person_ix_first_name_last_name 라는 이름으로 인덱스를 생서앟면 person 테이블의 이름과 성에 대한 인덱스라는 것을 이해하기 쉽다.

제약 조건

인덱스와 유사하게 제약 조건도 설명적인 이름을 지정해야 한다.

위반된 제약 조건이 발생하면 잘못된 삽입을 확인하는 것이 훨씬 쉽다.

CREATE TABLE team (
  id          bigserial PRIMARY KEY,
  name        text NOT NULL);

CREATE TABLE team_member (
  team_id     bigint REFERENCES team(id),
  person_id   bigint REFERENCES person(id),
  CONSTRAINT team_member_pkey PRIMARY KEY (team_id, person_id));

마치며

새 프로젝트를 생성하는 경우 위의 규칙들을 따르는 것이 좋다. 기존 프로젝트에서 작업하는 경우 새로 만드는 개체들에 대해 좀 더 주의해야 한다.

나쁜 명명 규칙보다 더 나쁜 것은 여러 가지의 명명 규칙이다. 기존 프로젝트에 데이터베이스 이름 지정에 대한 표준 방식이 있는 경우 그것에 따라야 한다.