프로젝트 주제에 따라 DB를 어떻게 구상할지, 뭐부터 구상할지 고민이신 분들이 계실겁니다.
저도 같은 고민을 겪었고 도움을 드리고자 제가 구상한 순서와 방식을 적어보겠습니다.
0. 주제 - 공동생활 어플리케이션
먼저 저희 프로젝트는 공동 생활을 하는 사람들을 타겟팅한 어플리케이션이었습니다.
그래서 제공한 주요 기능으로는 가계부, 캘린더, 피드가 있습니다.
1. 세부 기능 파악
앞서 주요 기능으로 가계부, 캘린더, 피드가 있다고 했습니다.
이제 주요 기능별 세부 기능을 논의해야 합니다.
제 경우에는 figma로 디자인해둔 저희 앱을 보며 세부 기능들을 분류했습니다.
예를 들어 가계부 기능의 경우에는
지출 등록, 서브카테고리 등록, 정산하기, 카테고리별 서치, 키워드 서치, 지출 수정/삭제, 서브 카테고리 수정/삭제 ···
처럼 다양하고 많은 세부 기능이 존재합니다.
작은 기능일지라도 그 기능 때문에 DB의 테이블이 생성되어야할 때가 있습니다.
그렇기에 꼭 세부 기능을 정확하게 파악해두는 편이 좋습니다.
2. DB 테이블 구상
방금 정리해둔 세부 기능을 토대로 테이블만 구상해봅니다.
가계부 기능의 경우에 필요한 테이블은 다음과 같습니다.
- 지출 테이블
- 카테고리 테이블
- 서브 카테고리 테이블
나머지 기능도 동일하게 필요한 테이블을 구상해보시길 바랍니다.
3. DB 테이블별 KEY 구상
각 테이블마다 필요한 요소를 구상해봅니다.
지출 테이블
→ 고유키(PK), 지출명, 지출액, 카테고리명, 서브카테고리명, 사용자
카테고리 테이블
→ 고유키(PK), 카테고리명
서브 카테고리 테이블
→ 고유키(PK), 카테고리명, 서브카테고리명
그런데 여기서 분명 외래키(FK)의 처치를 고민하실겁니다.
우선 어디 테이블에서 고유키를 끌고 와야할지(= 이게 FK입니다)는 나중에 생각하시고,
저렇게 테이블에 필요할 요소만 구상해보길 바랍니다.
그러면 저 요소 중 어떤게 외래키일지 서서히 감이 오실 겁니다.
4. 사용자 테이블 구상
가장 중요한 테이블일겁니다.
왜냐하면 사용자 테이블은 여러분이 앞으로 만들 모든 테이블과 연관될 예정이기 때문입니다.
PRIMARY KEY(고유키) : 테이블에 쌓일 레코드 별 고유한 키, 이 고유키를 다른 데에서 사용하면 FK라 부릅니다.
UNIQUE KEY(유일키) : 데이터베이스에 동일한 내역이 없습니다. 모든 내역은 유일해야합니다.
FORIEGN KEY(외래키) : 다른 테이블에서 우리 테이블로 가져온 PK입니다.
저희는 사용자 테이블 요소를 다음처럼 제작했습니다.
id : 고유키 (PRIMARY키)
userName : 사용자 이름
userColor : 사용자 색
email : 사용자 email (UNIQUE키)
groupId : 소속 그룹 ID (FOREIGN키)
birth : 사용자 생년월일
sex : 사용자 성별
createdAt : 가입 날짜
updatedAt : 업데이트 날짜
password : 비밀번호
(varchar는 string이라 생각하면 됩니다.)
5. 형식 지정
사용자 테이블까지 구상하면 이제 더 제작할 테이블은 없을 겁니다.
그럼 다음으로 중요한 키의 형식을 지정할 차례입니다.
앞서 보여드린 사용자 테이블에 의아한 부분이 있을 겁니다.
'id / sex / birth가 varchar네?'
하고 갸우뚱하실겁니다..
네, 저희는 저 부분을 int가 아닌 문자열로 지정해두었습니다.
그 이유는 말하자면 길지만 개발할때 저 편이 더 편했기 때문입니다ㅋㅋ...
형식은 여러분들이 자유롭게 정해두시고, 개발을 하며 언제든 수정하시면 됩니다!
5-1. 형식 지정 tip
int와 varchar 고민
- 웬만하면 varchar가 낫다!
왜냐하면 int형식이 프론트와 데이터를 주고받기 어려웠던 적이 많습니다.
int냐 float냐 이야길하다가 그냥 편하게 varchar(=string)로 지정한 기억이 있습니다.
- 단 예외도 있음!
저희는 그룹 코드로 다른 유저가 가입하는 기능이 있습니다.
이 기능을 구현하려면 그룹별로 그룹코드가 있어야합니다.
그래서 고유키를 그냥 그룹코드로 지정했습니다.
청팀 : ELFAV6VO 백팀 : ORVA4F8D
6. 마무리
저희 팀이 프로젝트가 처음이라 그랬을 수도 있지만
DB는 생각보다 자주 바뀌고, 개발을 하는 막바지까지 바뀝니다..
처음부터 완벽한 DB는 없습니다!
그렇지만 가능한 꼼꼼하게 구상을 하시면 수정하는 번거로움이 줄어들 수 있습니다.
그럼 모두들 성공적인 프로젝트 진행하시길 기원합니다!
'🎞️ 컴퓨터과학 : CS' 카테고리의 다른 글
| 알고리즘 플로우차트 작성 방법 | 플로우 정리하는 법 | 플로우차트란? (3) | 2024.04.17 |
|---|
