런픽 | EP02-1. ERD 설계 - 유저, 인증 및 러닝화

 

 

이제 작성한 와이어 프레임을 기반으로 하여 ERD를 작성해보려고 한다.

런픽 | EP01. 와이어 프레임 제작

 

실제로 개발 업무를 할 때에는 개발 설계 및 코딩할 때 기획자분께서 작성해주신 기획의 명세들을 기반으로 진행하지만, 혼자서 진행하다 보니 되게 명확하고 구체적인 요구사항들을 작성하기가 생각보다 귀찮다.. 그리고 기획과 개발 사이에서 발생할 수 있는 커뮤니케이션 부재가 존재하지 않는 상황이라서 erd를 설계하면서 더 디테일한 사항들을 캐치할 수 있을 것 같아서 곧바로 erd 설계를 진행해본다.

 

erd 설계는 dbdiagram.io라는 툴을 이용했다.

dbdiagram.io - Database Relationship Diagrams Design Tool

 

코딩할 때 사용할 DB는 PostgreSQL, 즉 RDBMS를 사용할 것인데 실무에서 우리팀의 경우 MongoDB만 사용하고 있기 때문에 관계형 데이터베이스에 대한 지식이 한없이 하찮다... 물론 개발자로 취업 준비를 하면서 MySQL을 다뤄보고 erd 설계도 해봤지만 이 경험 역시 맛보기 수준이라 깊이가 매우 미천하다. 그래서 이번 프로젝트가 개인적으로 많이 기대되는 부분도 있다. 뭔가 처음으로 각잡고 관계형 데이터베이스를 다루게 되는 것 같아서?

 

추가로 MySQL이 아닌 PostgreSQL을 선정한 이유로는 예전에 백엔드 프로젝트를 진행하면서 MySQL을 자주 사용했었는데, 정확히 기억은 나지 않지만 내가 원하는 데이터 처리를 하는데 있어서 MySQL에서는 지원하지 않는 기능들이 있었다. 하지만 PostgreSQL은 내가 원하는 데이터 처리를 할 수 있는 최적화된 기능이 있었고, 기회가 된다면 PostgreSQL을 사용해보고 싶다는 생각을 했었다(물론 내가 쿼리를 제대로 작성하지 못했었기 때문이었겠지만...). 여하튼, 진짜 ERD 작성 고고고

 

유저 테이블(users)

가장 먼저 기본적인 users부터 작성해봤다.

프로필 이미지 컬럼의 경우 추후 클라우드 스토리지 서비스를 통해 파일을 관리할 것이기 때문에 파일의 경로나 url만을 여기에 저장할 거라서 varchar 타입으로 설정했다.

 

리프레시 토큰 테이블(refresh_tokens)

이 웹애플리케이션은 JWT방식으로 인증 및 인가 시스템을 구현할 예정이다. 인증 프로세스는 실무에서 적용하던 방식을 기반으로 구현하고, 여기에서 디바이스의 개수에 따른 인증 제한도 만들려고 한다(다만 다른 기능들보다는 우선 순위가 낮을 듯).

리프레시 토큰은 하나의 유저가 여러 개를 가질 수 있으므로 1:N 관계로 설정했다.

 

러닝화 관련 테이블들

와이어 프레임을 보면 러닝화와 관련된 데이터들은 러닝화의 브랜드와 이름, 러닝화 설명글, 그리고 이미지들이 필요하다.

 

그리고 각 유저는 러닝화 하나에 하나의 좋아요를 누를 수 있다. 즉 복합 유니크 인덱스를 사용해야 한다. 복합 유니크 인덱스는 테이블에서 두 개 이상의 컬럼을 조합하여 그 조합이 유일하도록 보장하는 인덱스라고 한다. 즉 좋아요는 하나의 유저, 하나의 러닝화를 조합해야 하고 이를 SQL문으로 작성한다면 다음과 같을 것이다.

CREATE TABLE liked_shoes (
    id INT PRIMARY KEY,
    user_id INT,
    shoes_id INT,
    UNIQUE (user_id, shoes_id),
    FOREIGN KEY (user_id) REFERENCES users(id),
    FOREIGN KEY (shoes_id) REFERENCES running_shoes(id)
);

 

여기까지 정리한 erd는 다음과 같다.

 

여기서 한 가지 고민되는 점. 러닝화의 좋아요 개수는 테이블에서 관리하는 것이 나을까? 아니면 WAS 레벨에서 동적으로 계산하는 것이 나을까? 이와 관련해서는 AI놈에게 물어봤는데 다음과 같은 답을 해줬다.

 

언젠가 redis와 같은 메모리 데이터베이스 사용까지 확장을 생각은 하고 있지만 지금 당장은 사용하지 않을 것이기 때문에 애플리케이션 레벨 혹은 데이터베이스 내에서 해결해야 하는데 일단은 따로 테이블(liked_shoes_count)을 생성하기로 결정했다. 추후에 redis를 통해 해당 데이터는 캐싱 처리 하는 것을 고려해봐야겠다. 또한 러닝화의 조회수와 관련된 테이블도 추가했다. 여기까지 정리한 테이블은 아래와 같다.

 

리뷰와 관련된 erd는 다음에 정리..!