TIL [0630] : 1주차 - 연관관계 파악 및 ER-Diagram 작성

ERD 다이어그램

연관관계 작성

User - Cart

1:N 관계

유저는 여러 장바구니 {선택 옵션, 옵션 개수}들을 가지고 있다.

Product - Option

1:N 관계

상품은 여러 개의 옵션을 가지고 있다.

Cart - Option

1:1 관계

유저의 장바구니 하나는 하나의 옵션을 가지고 있다.

User - Order

1:N 관계

한명의 유저는 여러 번의 주문을 할 수 있다.

Order - Item

1:N 관계

주문 하나는 여러개의 결제 상품을 가질 수 있다.

Option - Item

1:N 관계

하나의 옵션은 여러개의 결제 상품을 가질 수 있다.

ex1) 유저가 옵션을 재주문했을때 한 옵션에 대해 결제 상품 여러개를 가질 수 있다.
ex2) 여러명의 유저가 같은 옵션을 구매했을때 한 옵션에 대한 결제상품은 여러개이다.

 

Order - Delivery

1:1 관계
주문 하나는 하나의 배송정보를 가질 수 있다.
주문시 배송지를 하나로 고정하는 것 (주문 N:배송지 1) 이 아니라, 
주문마다 배송지를 바꿀 수 있도록(주문 1:배송지 1) 구현하는게 비지니스적으로 좋을 것 같기 때문이다.

Q&A

❓ Q1. 비지니스 로직 - DB(팀원 질문)
Django ORM이나 JPA와 같은 ORM을 사용 하다보면 비즈니스 로직에 따라 쉽게 테이블 구조 등을 변경하는 경우가 많은데, 어떻게 하면 비즈니스 로직에 쉽게 흔들리지 않는 테이블 설계를 할 수 있을까요?

멘토님 👨‍💻 :
개인적으로 정규화를 잘할 수록 괜찮고, ORM에 따라 테이블 구조가 변하기보다는 비즈니스 로직이 테이블 구조를 변경시키는 경우가 많습니다.
그러므로 비즈니스 로직을 수행하는 도메인 객체가 테이블 구조를 자주 변경시키지 않게 하는 것이 좋습니다.

 

예를 들어, 엔티티와 도메인을 분리하는 구조는 어떨까요?
JPA로 엔티티 설계하고(테이블), 비즈니스 로직을 도메인 객체가 수행하게 하는 것처럼 말이죠.
즉, 비즈니스 로직을 수행하는 것과 테이블 설계 를 하는 것을 분리하는 방법을 추천합니다.

 

 

❓ Q2. 데이터베이스 공부 (팀원 질문)
백엔드 개발자로써 어디까지 데이터베이스에 대해서 공부를 하면 좋을지와 어떤 부분(ex: 최적화, 쿼리문법, 인덱스)들을 핵심적으로 꼭 알고 있으면 좋을까요?

멘토님 👨‍💻 :
일단은 지금 하고있는 데이터베이스 설계도 매우 중요하고, 쿼리 문법도 매우 중요합니다.
그 이유는 최적화할 때 인덱스, 조인 테이블 순서등에 의해 세부적으로 쿼리를 바꿔야 하는 경우가 많기 때문입니다.
Real MySQL 8.0책을 공부하면 데이터베이스 때문에 부족하다는 느낌을 받지 않을 것입니다.

 

 

❓ Q3. 추천 데이터베이스 (팀원 질문)

RDBMS을 제외한 NoSQL같은 다른 데이터베이스들을 공부 하고 싶다면 추천하고 싶은 데이터베이스가 있으실까요!

멘토님 👨‍💻 :
개인적으로 Redis를 추천합니다. 많이 사용되기 때문입니다.
캐시나 토큰을 보관하는 스토리지등 활용방식이 다양합니다.
문서를 담는 데이터로는 MongoDB를 추천합니다.

 

❓ Q4. 데이터베이스 필드 범위 (내 질문)

데이터베이스 설계시 데이터 타입의 범위를 어느정도로 설정해야 좋을까요?

어제 daily scrum에서 비지니스 로직이 담기지 않게 여유롭게 크기를 설정하라고 하셨습니다.

예를 들어 password가 20글자 이내여야 할때, 크기를 여유롭게 두려면 varchar(50)으로 두는게 좋을지 아니면 varchar(100) 또는 varchar(255) 로 두는 것이 좋을지 고민이 됩니다.(범위 설정?)

 

그리고 글자 크기를 어느정도 할지 임의로 설정해서 살짝 불안한 마음이 큰데, 이런 업무는 실무에서 데이터베이스 설계하는 분들이 하시고 저희는 결정 내용을 전달받는건지도 궁금합니다

멘토님 👨‍💻 :
varchar(255)로 두어도 최적화에 크게 영향을 미치지는 않습니다.
그리고 현업에서는 DB 설계하는 분들과 회의를 통해서 해당 사항을 결정합니다.

 

❓ Q5. 데이터베이스 필드 Type (내 질문)

• 테이블 설계시 언제 인덱스를 함께 생성하는 것이 좋을까요?
• 실무에서는 외래키를 잘 사용하지 않는다고 하는데, 외래키를 사용하여 다른 테이블을 참조하는 것이 좋을지, 인덱스를 사용해서 다른 테이블을 참조하는 것이 좋을지 궁금합니다.

멘토님 👨‍💻 :
일단 쿼리를 짜고, 느린 쿼리가 있을 때인덱스를 결정합니다.
부하 테스트의 경우에, 느린 쿼리가 있을때 인덱스를 걸고 쿼리를 최적화합니다.

실무에서 외래키를 안쓰는 이유는 성능 이슈때문입니다.
하지만 저는 외래키와 인덱스 사용을 결정하는 것은 각각 장단점이 있는 tradeoff라고 생각합니다.

 

• 외래키 사용시 정합성을 지킬 수 있지만 데드락 이 걸릴 수 있습니다.
• 인덱스 사용시 성능이 좋지만, 정합성 단점이 있습니다.

현재 프로젝트에서는 외래키를 사용하여 db가 알아서 정합성을 보장하는 방식을 사용하는 것이 더 적절해 보입니다.