[24.01.04]

ERD 설계

내배캠 최종 프로젝트에 진입하면서 ERD를 설계하게 되었다.

1. 식별관계 - 비식별관계 구별

식별관계와 비식별관계는 참조를 하는 테이블(자식 테이블)과 참조를 당하는 테이블(부모테이블) 사이에 맺어지는 관계이다.

일단 식별관계의 정의는 부모 테이블의 기본 키가 자식 테이블의 기본 키로 할당되는 관계이고

비식별관계는 부모 테이블의 기본 키가 자식 테이블의 외래키가 되는 관계이다.

 

고로 식별관계는 부모 테이블에 참조하고자 하는 데이터가 없다면 자식 테이블의 데이터 생성이 불가한 구조이다.

식별관계의 장점으로는 데이터의 정합성을 보장해준다는 점이 되겠다.

그러나 테이블간의 제한사항이 빡빡하기 때문에 테이블 관리가 어렵고 비즈니스 로직 변경 시에 난항을 겪을 수 있다.

 

프로젝트에 따라 관계를 적절히 설정하는 것이 좋다고 하지만 현업에서는 웬만하면 비식별관계로 설정하는 경우가 많다고 하니, 복합키 같은 특수한 경우가 아닌 이상 비식별관계로 설정하는 것으로 결정했다.

 

2. 일대일 관계를 맺을 것인가?

테이블 설계를 고민하다가 유저 정보와 유저 프로필에 대한 테이블을 따로 만들자는 팀원 분의 의견이 있었다.

유저 정보에는 인증/인가에 대한 내용을 담고 프로필에는 라이트한 데이터를 담으면 독립성 측면에서 좋다는 의견이었다.

나도 오 뭐 나눠서 나쁠 게 있을까? 라는 생각으로 동의하였는데 후에 튜터 님의 조언으로 테이블을 수정하게 되었다.

일대일 관계의 테이블은 최소한으로 만드는 게 좋다는 말씀이었다.

 

일단 테이블 수를 최대한 줄이는 것이 전체 테이블을 관리하는 데 용이하고

컬럼이 엄청 많은 것이 아니라면 부모 테이블 데이터의 외래키를 찾아 탐색하는 비용이 또 증가하기 때문에 

일대일 관계 테이블은 최소화하는 것이 좋을 것이다.

 

3. 새로운 테이블 구현방식

하이브(모임) 나 파티(약속)에 변동사항이 생기면 유저에게 알림을 보내주는 기능을 구현하려 했다.

그러면 알림 테이블에 하이브와 파티의 기본 키를 외래키로 가져야 하는데 다대다 관계이기 때문에 이를 테이블로 만들 경우 테이블 구조가 너무 복잡해지는 상황에 봉착했다.

해결 방법은 테이블간의 관계를 맺는 대신 우리가 필요한 건 참조관계까지는 아니기 때문에

알림 테이블 컬럼에 하이브, 파티 둘 중에 어떤 엔티티의 알람인지 + 엔티티(하이브 or 파티)의 기본 키.

이렇게 두개의 컬럼을 추가하여 해결하였다 신박하였다.

 

 

느낀 점

진짜 팀장급 실력 아닌데 리더를 맡게 되어서 힘들지만 오히려 기회다 화이팅하자.