database 이름 짓기

안녕하세요. Class명, 변수명, REST API의 명 등 이름을 짓는 일은 개발에서 가장어려운 부분중 하나라는 점은 다들 공감하실 것이라 생각합니다. 프로젝트에 참여하는 모두가 공감대를 가질 수 있어야 하며 명확해야하기 때문입니다. 그래서 큰 프로젝트에서는 명명 사전, 축약 사전등을 만들어놓고 사용하기도 합니다.

database의 table, column 등의 이름을 정하실 땐 어떻게 하시나요? 컬럼은 대문자...? 축약어는 많이 사용하시나요?

오늘은 database의 이름짓는법에 대해서 알아보도록 하겠습니다. 영어권에서의 명명법을 찾아서 번역 및 정리한 자료라 우리나라와는 맞지 않는 부분이 있을 수도 있습니다. 참고의 용도로 봐주시면 감사하겠습니다.

명명 규칙의 중요성

이름은 오래간다

데이터 구조는 어플리케이션 코드보다 훨씬 지속력이 높습니다. 잘 정의된 데이터 구조와 테이블 레이아웃은 어떠한 어플리케이션에서도 사용되어질 수 있습니다. 즉, 데이터 구조는 한번 잘 짜 놓던 아니던 영향력이 오래갑니다.

이름은 계약이다

한번 컬럼이나 테이블 이름을 정해놓으면 어플리케이션에서는 그 이름을 코딩으로 사용합니다. 만약 컬럼과 테이블의 이름이 변경된다면 의존하고 있던 어플리케이션에서도 수정이 일어나야 합니다.

개발자 환경의 차이

이름이 잘 정의된 테이블, 뷰, 컬럼이 있다면 본인 뿐만 아니라 다른 개발자들도 데이터베이스의 구조를 이해하는데 짧은 시간이 소모될 것입니다.

명명 규칙

소문자(Lowercase)

테이블, 뷰, 컬럼을 비롯한 모든 식별자들은 소문자로 작성하는 게 좋습니다. 대소문자가 섞여있는 식별자 이름들을 사용하는 건 좋지 않습니다. 이유는 예약어들과 구분짓기 위함입니다. ORM에서 자동으로 테이블을 생성하면 소문자로 출력되는 것도 이런 규칙을 지키는 게 아닌가 싶습니다.

ex) first_name으로 사용하는 것이 First_Name으로 사용하는 것 보다 좋습니다.

• 이후 테이블, 뷰, 컬럼들을 모아서 object라고 표현하도록 하겠습니다.

데이터 타입을 이름으로 정하는 것은 피하자

ojbect에 type을 이름으로 사용하면 안됩니다. 특히 컬럼명도 명사로 지어야 합니다. 컬럼명에 type명을 사용하는 것은 좋지 않습니다.

ex) text, timestamp 등은 좋지 않은 컬럼명입니다.

복합어구에는 _를 사용하자

여러 글자가 합쳐져 만든 복합어구에는 _(snake_case)를 사용하는 게 좋습니다. camel_case 등은 좋지 않습니다.

ex) wordcount, wordCount보다는 word_count, team_member_id가 좋습니다.

축약어보다는 풀네임을 사용하자

Object 이름들은 약어를 사용하기 보다는 풀네임을 사용하는게 좋습니다. 대부분의 SQL 데이터베이스는 30자 이상의 Object 이름을 설정할 수 있도록 지원하고 있습니다.

ex) middle_name이 mid_nm보다 좋습니다.

약어를 사용해야할 때는 공통적인 약어를 사용하자

어쩔 수 없이 약어를 사용해야한다면, 공통적으로 사용하는 약어를 사용하는게 좋습니다.

• 저는 https://www.curioustore.com/#!/util/naming 이 사이트를 자주 이용합니다.

단수 명사

table, view 들은 단수의 명사를 가지는게 좋습니다.그 이유중 첫번째는 일반적인 경우 다른 테이블과의 관계를 맺을 때 1개의 row와 관계를 맺기때문이며, 두번째는 어플리케이션에서 이름을 명명할 때 혼란이 없기 때문입니다.

ex_1) teams보다는 team으로 테이블이름을 짓는게 좋습니다.
ex_2) team_member는 java라면 teamMember가 되면 되고, python에서는 team_member로 사용하면 됩니다.

Key Fields

• primary key

단일 컬럼 primary key라면 이름을 id로 짓는게 좋습니다. id는 짧고, 단순하고 명확합니다. 이렇게 이름의 key를 단일화 한다면 join할때에 key를 햇갈릴 일이 적어집니다. 몇몇 가이드에서는 {table명}_id를 사용하길 권장합니다. 개인적으로 {table명}_id는 이미 이름에서 중복이 일어나서 불필요하독 생각합니다. 선택은 본인의 자유이기때문에 본인에 맞게 선택한다면 좋을 것 같습니다.

• foreign key

foreign key 필드는 {참조되는 테이블}_id의 이름이 좋습니다. 이역시 짧고, 단순하며, 명확하기 때문입니다.

Prefixes and Suffixes (bad)

• Relation Type 선행

몇몇 옛날 가이드라인들은 테이블이면 TB_, 뷰면 VM_ , 프로시져면 SP 등 prefix를 붙여주는게 좋다라고 하는 가이드들이 있었습니다. 이렇게 prefix를 붙이면 프로그래머들이 즉시 이게 어떤 Object인지 알 수 있다는 장점이있습니다. 하지만 이렇게 해버리면 만약 뷰의 경우 테이블로 전환하게 되면 원래 가지고 있던 SQL 쿼리 등 수정해야 하는 부분이 많이 생기게 됩니다.

• Data Type 행

컬럼과 같은 필드에 type을 추가하는 건 어떨까요? 예를 들면 text 필드라면 name_tx 이렇게 말이죠. 좋지 않은생각입니다. 컬럼의 타입은 변경될 수 있습니다. 만약 timestamp형이 었던 date가 varchar로 변경될 수 있습니다. 그렇기 때문에 붙이지 않는것이 좋습니다.

자동 생성되는 이름

hibernate(JPA 등)과 같은 ORM을 이용하다보면 이름이 자동으로 생성되는 경우가 있습니다. 제약조건이나 Index이 대표적인 예입니다. 이런 제약조건과 Index또한 이름을 제대로 지어 줄 필요가 있습니다.

index의 경우 {table 이름}_ix_{column_1}..{column_2}... 가 좋으며 제약조건 이름 역시 {table 이름}\_{제약조건 이름}으로 명확하게 하는게 좋습니다.

예제는 아래와 같습니다.

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);

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));

마무리

이렇게해서 오늘은 database의 이름을 짓는 방법에 대해서 알아보았습니다.

저도 이름짓는게 참어려웠고 지금도 많이 헤메이고 있습니다. 여러분들에게도 저에게도 도음이되었으면 하는 바램입니다.

감사합니다.

참조

https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/