[DB] 02. DB 컨벤션 규칙
movester DB 컨벤션
1. 약어 사용 자제
약어를 사용할 시 앞단어가 비슷하거나 스펠링이 비슷하다면 “이게 도대체 어떤 단어의 약어야!” 하기가 쉽다. 그러므로 최대한 약어 사용을 줄이도록 한다.
ex) stretchingWeeckly 테이블에서 요일별로 스트레칭을 담기 위해 각각의 칼럼명은 Mon, Tue, Wed …로 했다. 욕을 엄청 먹었다..ㅎ
Frequently Asked Questions (자주묻는질문) 은 FaQ가 당연시 되어있기 때문에 (QnA와 같은 의미로) faq로 사용하도록 한다.
2. 테이블, 칼럼명은 모두 단수
테이블과 칼럼명을 단수로 하느냐 복수로 하느냐는 말이 많은 것 같다.
나는 고민끝에 단수로 하기로 했다.
복수처리할때 s냐 es냐의 문제를 고민하고 싶지 않았으며, 나는 그나마 단어가 조금이라도 짧았으면 했다.
3. 테이블명은 카멜 케이스
테이블명에 스네이크 케이스를 둔다면, 전포스팅에서 나의 실수와 같이 idx를 나타낼때 단어_단어_idx 사태가 나타날 수 있다. 이를 방지하고자 테이블명은 카멜케이스를 사용하도록 하자.
테이블 위의 도메인 테이블이 있다면?
난이도 테이블의 경우 스트레칭 마다 하나의 난이도를 갖는다. 즉 난이도테이블은 스트레칭 테이블을 도메인으로 갖는다. 이 경우 도메인을 테이블 명 가장 앞에 두도록 한다.
- 이는 추후 다른 난이도를 표시하는 게 생긴다면 테이블명의 중복이나 헷갈림을 방지할 수 있다.
- 이 규칙에 따라 winner > eventWinner 로 변경된다.
- userLike, userRecord 테이블의 경우 user와 stretching 두 도메인을 모두 받게된다. 이 각각의 테이블은 마이페이지 기능에 사용되므로 user에 좀 더 초점이 있다 보고 user 만 테이블명 앞에 두기로 하였다.
4. 칼럼명은 스네이크 케이스
개인적으로 각각의 컨벤션 중에 여러 단어가 합쳐졌을 때 내가 시각적으로 가장 구분이 잘 되는 컨벤션이 스네이크 케이스였다. 내가 코딩할때 가장 많이 접하는 것은 테이블명보다는 칼럼명. 즉 변수명이므로 칼럼명은 스네이크 케이스를 선택하였다.
1. idx
나는 테이블마다 각각의 기본키로서 (인덱스 역할을 위한) idx 를 두었다. 각각의 idx는 테이블명_idx로 하도록 한다.
2. 예약어는 칼럼명으로 사용하지 않는다.
이건 정말 당연한건데 생각을 못했었다. ex) 난이도 테이블의 값 : value로 두었는데 이는 예약어다!
3.이분법으로 나눠지는 값은 ‘_‘flag 사용
노출 여부 처럼 한다/안한다 의 이분법 개념이라면 _flag를 사용한다.
하다보니 궁금증이 생겼다.
각 테이블마다 title, contents 칼럼이 많이 등장하는데 변수명만 보더라도 어떤 테이블의 변수인지까지 알기위해 테이블명_title, 테이블명_contents로 지어줘야할까..?
writer의 경우 각각의 글의 작성자이다. 하지만 이 값은 user테이블의 user_idx값을 외래키로 갖는다. 이 경우, 외래키로 사용되는 테이블에서 (ex 공지사항) 칼럼명을 writer 로 해야할까 user_idx로 해야할까? 물론 값은 user_idx를 넣을 것이다.
답을 찾는다면 적겠다!
