[멘토링] ERD 설계 시 강한 결합(식별 관계) 선정 기준 (jayden.bin)

[codeok2]

🙋질문자

판교 3기 / 5조(개발자지만 독서는 하고싶지?) - bruni.kim(김범석)/풀스택

🙋답변 희망 멘토

jayden.bin(김한빈)/@konempty

궁금한 내용

• 서비스에 대한 ERD를 설계하는 단계에서, 엔티티간의 관계를 설정하는 과정에서 강한 결합은 어떤 상황에서 사용하는 것이 적절한지 궁금합니다.
• erdcloud : (https://www.erdcloud.com/d/r4Z6Ryjou2Qb2GPH2)

시도한 방식

• 엔티티간 관계를 표현할 때, 강한 결합(식별 관계)는 자식 엔티티가 부모 엔티티에 종속적인 관계에 있을 때 사용하는 것으로 알고 있습니다. 즉, 부모 엔티티가 존재하지 않을 때 자식 엔티티 또한 존재 가치가 없는 경우, 그리고 자식 엔티티는 부모 이외의 엔티티에서 참조하지 않을 경우에 사용하는 매핑 관계라고 이해를 하고 있습니다.

• 이를 바탕으로 저희 서비스에 있는 채팅방 엔티티의 자식 엔티티인 채팅방 라운드 엔티티는 부모인 채팅방 엔티티에 의해 존재 유무가 결정되고, 부모 엔티티 이외의 다른 곳에서 참조가 필요하지 않기 때문에 강한 결합으로 관계를 표시하였습니다. 이와 비슷한 논리를 바탕으로 ERD의 관계를 매핑하다보니 강한 결합 관계가 여러 곳에서 나타나게 되었습니다. 하지만 개발 초기 단계에서 강한 결합의 경우 이후 확장성을 고려하여 최소한의 관계에서만 신중히 사용해야 한다고 알고 있기 때문에 설정한 결합 관계에 대해 확신을 못하고 있습니다.

이제 어떻게 하려고 하는지?

• 개발 초기단계에서는 안전한 비식별 관계 매핑으로 변경하는 방향으로 생각하고 있습니다.

추가 참고자료 (선택사항)

• #ERD, #강한결합관계(식별/Identifying)

[konempty]

@codeok2
안녕하세요 브루니~!
어려운 주제로 고민하고 계시는군요 ㅋㅋㅋ
일단 질문 주신 내용은 뚜렷한 답이 있는 문제는 아니예요.
말그대로 개발 컨벤션의 영역이라 여러분들이 정하기 나름이죠
다만 참고할만한 지표는 있는데 브루니가 적어주신대로 결합을 많이 걸어두자니 추후 확장성에 제약이 생기고
안하자니 개발 편의성이 낮아지고 혹시나 모를 실수에서 방어가 안되죠

그렇기에 예시를 들어서 설명하자면 저는 멘토링때 말씀드린것처럼 계약과 정산 플랫폼을 개발하고 있는데
말 그대로 현실의 계약 조건을 어떻게든 코드로 녹여내고 그 내용을 DB에 저장해야하다 보니 확장성을 많이 고려한 설계가 필요해요
그렇기에 저희는 각 엔티티 사이의 결합을 낮추려고 하고 카스케이드, FK등 많은 개발 편의성을 포기한 개발을 하고 있어요.

그런데 반대로 인증서 시스템은 매우 보수적이면서 안정성이 매우 중요한 시스템이고 인증서 시스템의 구조는
수십년전 PKI 시스템에서부터 현대의 공동/사설 인증서까지 형태가 거의 불편했어요.
그렇기에 신규 기능을 추가하기에 편하도록 강력한 결합을 사용하고 그걸 제약조건으로 사용해서
제약 조건에 어긋나는 데이터는 들어가는걸 원천차단하여 안정성을 높혔죠.

또한 한 시스템 내에서도 엔티티별 요구사항이 다를수도 있죠
따라서 브루니와 팀원들이 개발할 프로젝트가 어느 방향에 가까운지는 여러분들이 더 잘 아실테고 그에 맞게 고민하시면 좋을것 같아요!
그래도 제 의견을 더해보자면 채팅만 보자면 상당히 안정성과 정합성이 중요한 시스템이구요.
확장성은 상당히 제한적인 시스템이죠 기껏해야 사진&동영상보내기, 이모티콘 보내기 정도가 확장 가능한 범위로 예상이 돼요
그렇기에 지금 부정적으로 생각하시는 강한 결합도 잘 어울릴수 있을것 같다고 생각해요!
그래도 선택은 트레이드 오프를 잘 고려하셔서 여러분들의 의견으로 정해졌으면 합니다~!

ps) ERD보다가 우려사항을 발견했는데

DB에다가 유니크 인덱스 자체는 좋은데 case문처럼 if-else로직을 넣거나
check같은걸로 비즈니스 로직을 DB에 녹여내는건 성능면에서나 유지보수면 모두에서 좋은 선택지는 아니예요.
요런건 코드에서 보장을 해주는게 좋습니다!
특히 회사에선 DBA분들이 매우 꺼려하세요 ㅋㅋㅋㅋ

[codeok2]

@konempty
안녕하세요 제이든!
먼저 실제 경험하셨던 예시를 들어주시면서 자세히 답변 주신점 정말 감사합니다!

반대되는 상황에 대해 관계성 선택 차이를 말씀해주셔서 각 관계가 어떤 상황에서 더 잘 맞는지 이해하는데 도움이 되었습니다.
다만 한가지 의문이 든 부분이 있는데,
첫 번째 상황에서 확장성을 고려한 설계가 필요한 상황에서 엔티티 사이의 결합을 낮추려고 하셨고,
두 번째의 반대되는 상황에서도 신규 기능을 추가하기에 편하도록 강력한 결합을 사용하셨다고 하신 부분에서
확장성(신규 기능)이라는 동일한 목적을 위해 서로 상충되는 엔티티 결합(엔티티 결합 낮추기 vs 강력한 결합 사용)을 사용하셨다는 부분에서 의문이 들었습니다.

강한 결합은 안정성은 높지만, 확장성은 낮고(개발 편의성이 낮음) 약한 결합은 확장성은 높지만(개발 편의성 높음), 안정성이 떨어진다 라고 이해하고 있는데, 혹시 제가 잘못 이해하고 있는걸까요?

추가로, 저희 채팅 시스템에 대한 특징에 대해서도 설명해주셔서 감사합니다. 답변주신점 기반하에 팀원들과 상의하여 결정하도록 하겠습니다!

DB에는 비즈니스 로직을 녹여내지 않는점 명심하겠습니다.
감사합니다!

[konempty]

@codeok2
일단 제가 드린 답변이 조금이라도 도움이 되었다니 다행이네요 ㅎㅎ

추가 질문에 대해서 답변을 드리자면
네네 이해하신게 거의 맞는데 확장성이 낮다고 해서 개발 편의성이 낮은가? 라고 하면 보통은 맞지만 항상 그런건 아니예요
새로 추가되는 기능이 기존의 기능와 크게 이질적이지 않거나 기존의 코드를 많은부분 재활용 할수 있다면
오히려 기존코드의 규칙이 철저하고 방향성이 확실한 쪽이 개발 편의성이 높을수도 있죠 (인증서 시스템의 신규기능은 보통 이에 해당해요)
또한 강한 연관관계를 쓴다면 엔티티들 사이와 이동이라고 해야할까요? join을 걸어서 한 엔티티를 가지고 다른 엔티티의 정보에 접근하는 식의
기능에는 개발이 훨신 편해지게 되죠
이 경우 오히려 연관관계가 없다면 한 엔티티에서 다른 엔티티의 정보를 join걸고 조회하는 과정이 오히려 힘들어 질 가능성이 있죠
그렇기에 말 그대로 엔티티들 사이의 관계를 이용한 연산과 코드가 얼마나 들어가는지도 강한 연관관계를 선택하는데 좋은 지표중 하나죠

따라서 새로 추가되는 기능이 얼마나 기존 기능과 이질적이냐에 따라 확장성의 자유가 도움이 되는것이지
새로운 기능이 기존기능의 방향성과 거의 일치한다면 강력한 규율은 오히려 도움이 됩니다!
이 부분도 트레이드오프의 예시죠