DB 설계 & ERD 자동화

[sodaMelon]

View detail

초안 작성에는 ERD 문서 자동화(dbdiagram, dbdocs)를 사용했다. (사유: 공유 편리함, 변경 편리함)

1. (실제 서비스에 적용할 때는) 성능&BOUNDED CONTEXT 관리를 고려하여, 의존 관계를 적절히 설정하는 것이 중요하다. 현재 코드에는 엔티티끼리 관계성이 없는데, (ORM의 사용 장점은 줄어들지만) ①변경이 잦거나 ②엔티티간 복잡도가 높은 환경에는 괜찮은 선택이다.

2. 개발 단계에는 혼자 개발함+빠른 개발을 위해 spring.jpa.hibernate.ddl-auto: update 을 create-drop을 반복해가며 완성했다. 이 때 MYSQL의 경우 TYPE(varchar, int 등 )가 기본값(예: LocalDateTime의 경우 DateTime)으로 생성될 수 있는데, 성능적으로 생각해볼 문제들이 있다. (코멘트로 남겨질 예정)

   • [ ] ① UUID ( BINARAY VS VARCHAR)
   • [ ] ② LocalDateTime ( TIMESTAMP VS DATETIME)
   • [ ] ③ ENUM (VARCAHR VS ENUM )

3. 서브쿼리 지양 (쿼리를 나눠서 실행하거나, join을 통해서 해결하도록 한다.)

[sodaMelon]

1. UUID BINARAY 채택(하였으나... DB 관리 TOOL로 접근 시, 바이너리라서 전처리 또는 후처리를 고쳐야하는 번거로움이 있으므로 좀더 고려 필요할듯) UUID 버전은 ver2를 사용하였는데, 용도에 따라서 좀 더 조절할 수 있을듯. 참고링크

[sodaMelon]

② LocalDateTime ( TIMESTAMP VS DATETIME) TIMESTAMP 채택(마찬가지로 숫자형태이므로 전처리 필요..)

두 자료형 모두 각각 이점이 있긴한데, 이 서비스는 '뉴스 피드, 알림서비스' 이므로 인덱스를 지원하는 TIMESTAMP 를 골랐다.

[sodaMelon]

③ ENUM (VARCAHR VS ENUM ) VARCHAR 채택 확장에 열린 구조여야함. (+실시간 서비스 환경에서는 DB변경 어려움)...

정말 유동적일이 없는 구조 (예를 들면 요일 MON, TUS...)같은 경우에는 도입해도 괜찮을 수도 있으나. 좀더 검토가 필요할듯...