코딩짜는 일상

[DB] 테이블, 컬럼 이름 짓기 본문

IT 개발 팁

[DB] 테이블, 컬럼 이름 짓기

Remily 2022. 3. 17. 15:43
반응형

시작

개발자로 처음 구직을 할 때 간간히 보았던 문구가

이름 잘 짓는 분 찾습니다!였습니다.

그게 좀 신박하고 직관적인 이름을 선택할 줄만 알면 되는 줄 알는데...

회사에서 페이지 몇 개 만들면서 점점 쿼리가 복잡해지니까 알게 되었습니다.

 

중요한 건 쉽게 외울 수 있게 짓는 것이란 것을..!

 

 


 

테이블, 컬럼 이름짓기 규칙

  1. 테이블을 이름으로 세분화 하자.
  2. 컬럼 이름 앞엔 테이블 이름을 약어를 붙이자.
  3. 버전이 다른 테이블은 컬럼 이름을 같게 하자.

 

이유

1. 테이블을 이름으로 세분화 하자.

사이트에 기능이 추가될 수록 담아야 할 정보는 늘어만 갑니다.

 

로그인을 만들면 유저의 개인 정보를 저장해야 하고
게시판을 만들면 글쓴이 정보와 글 비번, 컨텐츠, 댓글을 저장해야 하고
상품판매 페이지를 만들면 사진과 내용, 결제정보, 택배정보 등등..

이렇게 기능을 추가할 때마다 새로 테이블을 만들게 됩니다.

 

 

 

여기서 상품판매 페이지를 예로 들어보죠.


만약 상품 리뷰 기능을 추가한다면?
추가구매 기능을 추가한다면??

 

이렇게 기능이 추가될 때 상품판매 정보가 들어있는 shop테이블에 칼럼을 계속 추가하면 될까요?
그러면 테이블이 무한정 길어지고 원하는 칼럼 이름을 찾는 데 시간이 오래 걸리진 않을까요?
그렇다고 너무 세분화 하면 JOIN을 여러번 써야하니 쿼리가 엄청 길어집니다.

 

 

첫번째 이유의 핵심은 적당히 세분화 하되

이 테이블에 주로 어떤 정보가 담겼을지 유추할 수 있도록 이름을 짓는 것 입니다.

 

 

인터넷 서점을 예시를 들어 볼까요?

 

인터넷 서점에는 크게 책을 사려는 사람, 책을 팔려고 하는 출판사 정보가 모일 것이고
책(상품) 정보와, 책을 사고 판 정보, 리뷰 등의 정보가 모일 것입니다.


대분류, 소분류로 나누자면 이렇게 되겠네요.

 

대분류 - 정보의 주체가 누구인지. 고객인지 출판사인지.
소분류 - 판매정보인지, 구매정보인지, 리뷰정보인지, 중고책인지, 관련 굿즈인지.

 

그리하여 새 책을 구매한 내용이 담긴 테이블

1) 정보의 주체가 고객이고
2) 구매한 정보이고
3) 산 물건이 새 책이니까
user_buy_book이 되겠군요.

 

중고 책이라면 user_buy_book_resale이 될 것이고 굿즈라면 user_buy_merchandise겠죠.

 

이 방법이면 Workbench에서 테이블 이름 순으로 나열해서 보기도 좋습니다.

 

 

 

2. 컬럼 앞엔 테이블 약어를 붙이자.

JOIN으로 테이블을 연결해 조회할 때 어느 테이블의 칼럼인지 알 수 없기 때문입니다.

유저 정보 테이블user_info의 인덱스도 index.
출판사 정보 테이블shop_info의 인덱스도 index.
주문 정보 테이블order의 인덱스도 index라고 해보죠.

 

주문번호 1234인 주문 정보를 로딩해 봅시다.

SELECT *
FROM order
WHERER index='1234'

그러면 거기엔 주문한 책의 index번호도 있을 것이고, 주문한 사람의 index번호도 있고
책을 판매한 출판사의 index번호와 택배를 진행한 택배사의 index번호가 있을 것입니다.

 

index는 Primary Key로써 엑셀로 따지면 그 행이 몇 번째 행이냐, 하는 정보입니다.
절대 다른 행과 겹치지 않아서 인식 번호정도로 생각하시면 됩니다.

 

그런데 이 인식 번호가 담긴 칼럼의 이름이 전부 다 index이다...?

 

그러면 출력되는 rows의 헤드에는 전부 index라고 적힐 것이며

우리는 이게 책의 번호인지, 사람의 번호인지, 출판사 번호인지, 택배사 번호인지 알 길이 없습니다.

 

하지만 테이블의 약칭을 컬럼 앞에 붙여준다면 어떨까요?!

 

고객userus, 출판사shopsp, 책bookbk

 

그러면 us_idx는 고객의 인덱스 번호일 것이고
sp_idx는 출판사의 인덱스, bk_idx는 책의 인덱스가 될 것입니다.

 

다른 방법으로는 고객 번호를 number, 출판사 번호를 figure, 책 번호를 numeral라고 짓는 식으로
소리는 달라도 뜻이 같은 단어를 선택하는 방법이 있습니다만... 솔직히 햇갈리죠? ㅎㅎ


매번 테이블의 칼럼 설명글을 읽어야 할지도 모르겠습니다.

 

 

 

3. 버전이 다른 테이블은 컬럼 이름을 같게 하자.

만약 인터넷 서점이 새롭게 출판업을 시작하였다고 가정해 봅시다.


그럼 다른 출판사들의 소설이 있을 것이고 인터넷 서점이 자체 출간한 소설이 있겠죠?

대분류는 출판사가 제공한 정보이므로 shop이 될 것입니다.

그럼 일반 소설 테이블은 shop_book_novel 독점 소설 테이블은 shop_book_novel_admin이 되겠네요.


그러면 아까 제 2 법칙을 적용해서 책 제목 칼럼을 nv_namenv_adm_name으로 지으면 될까요?

 

솔직히 그래도 상관은 없습니다만, 모든 칼럼마다 _adm을 더 타이핑 해야할 겁니다.
타자가 느리면 느릴 수록 쿼리 짜는 시간도 더 늘겠죠. 아무리 미미한 차이라 하더라도요.

 

그래서 똑같은 소설 인덱스 칼럼이니까 nv_name으로 통일하는 겁니다!
같은 소설 라인이라 왠만하면 JOIN으로 엮어 같이 조회하게 될 것이고.. 어짜피 테이블 명으로 구분을 지어뒀으니까요.

 

 

 


 

 

 

최종 예시를 들어 봅시다!


책은 등록될 때마다 shop_book 테이블에 bk_idx를 프라이머리 키로 하여 우선 등록됩니다.

이것은 부모 테이블이 됩니다.
이후 독점 소설과 일반 소설로 나뉘어 각각의 테이블에 저장되죠.

이것들은 자식 테이블이 될 겁니다.
이들 테이블을 연결하기 위해, 우리는 book테이블의 bk_idx를 연관칼럼으로써

각각 독점소설, 일반소설 테이블에 넣어 줍니다.
이것은 후에 JOIN을 쓸 기준이 됩니다.

 

이때 전체 소설 중에서 최근에 등록된 소설 10개를 조회한다고 해봅시다.

SELECT bk.bk_idx, nv.nv_name, nvad.nv_name
FROM shop_book bk
    JOIN shop_book_novel nv ON bk.bk_idx=nv.bk_idx
    JOIN shop_book_novel_admin nvad ON bk.bk_idx=nvad.bk_idx
ORDER BY bk.bk_idx DESC
LIMIT 10;

쿼리를 설명하자면 bk_idx는 프라이머리 키니까 등록될 때마다 숫자가 증가하며 다른 책과 겹치지 않습니다.
즉, 숫자가 크면 클 수록 최근 등록된 책이라 할 수 있겠죠! 그래서 ORDER BY로 내림차순 10개만 뽑습니다.

 

더불어 JOIN으로 일반 소설 테이블, 독점 소설 테이블을 연결하고
SELECT절에 두 소설들의 이름 칼럼명을 적어 조회한 것입니다.

 

 

 

어떤가요?
쿼리만 읽어도 테이블에 어떤 정보가 들어있을지, 불러낸 칼럼이 어떤 정보를 말하는지 알 것 같은가요?


이름만 잘 지으면 쿼리만 읽어도 어떤 내용일지 알 수 있습니다!!

반응형