우리의 프로젝트에서 섬세하게 터치한 부분중 하나는 RDB이다. 초기에 코드를 작성하기 좋은 방식으로 우선 작성하고 여러가지 변화를 거쳐왔다.
여기서 작성하기 편함이라고 한다면, 테이블 간에 관계에서 무조건 적으로 참조를 하며 Many To One관계를 활용하여 빠르게 작성한 것을 말한다. 이때는 기존의 관계는 작성은 편하게 가능하지만 반대로 삭제를 요하는 단계에서는 참조하는 연관관계로 인하여 삭제 불가능한 현상이 일어나는 사고가 있었다. 때문에 이 관계에서 불편점을 찾아 개선점을 마련하였다.
1. 퀴즈의 삭제 불가 현상
퀴즈를 삭제하려고 했지만, 현재 퀴즈는 여러가지 분야에서 참조당하고 있는 문제가 있다. 너무 복잡한 관계로 인하여 삭제가 불가능한 현상이 발견된다. 댓글, 문제, 선택지, 좋아요, 등의 이유로 인하여 연관관계에 대하여 다시 생각할 필요가 있었다. 이때 퀴즈가 단독으로 모두 소요한다고 생각한다면 One To Many의 관계 등 여러가지 방식이 있을 수 있지만 반멤버도 소유하고 있는 경우가 있기 때문에 고민점이 많아졌다.
2. 멤버의 삭제 불가 현상
위와 마찬가지로 좋아요, 퀴즈, 댓글 등에서 멤버를 참조하고 있기 때문에 삭제 불가능한 현상이 발생함 즉, 이를 통해서 가장 문제되는 현상을 발견함
3. 멤버와 퀴즈 둘다 소유하고 있는 현상
위의 두가지 상황으로 인하여 제일 큰 문제는 멤버와 퀴즈 둘다 소유하고 있는 문제라고 생각한다. 즉, 멤버와 퀴즈를 공동으로 참조하는 것으로 인하여 문제가 생겼다 정의하였다. 단독 참조의 경우 소유권을 변경하는 것과 비슷한 방식으로 조정가능하지만 동시 참조에 경우 누가 더 필요한가에 초점을 두고 관계를 아래의 사진과 같이 조정함. 즉, 동시에 참조하고 있던 멤버의 응답, 좋아요, 댓글 크게는 멤버와 퀴즈의 관계를 다시 정리함 .
퀴즈와 멤버 독립
멤버의 탈퇴에서 가장 문제된 것은 바로 퀴즈와의 연관성이다. 즉, 퀴즈로 인하여 삭제가 힘들다는 점, 동시 참조로 인하여 누구에게 초점을 맞출것인지 결정하는 문제로 인하여 서로의 관계를 독립시켜 각자 운영하는 식으로 하여 RDB의 구성은 크게 알림, 퀴즈, 멤버 3가지 분야로 구분되는 것으로 수정하였다.
소유권 결정
결국 가장 큰 문제를 해결하기 위해서는 동시에 참조하고 있는 것에서 어디에 좀 더 초점을 맞출것인가 라는 점이 주요 쟁점이였다. 이로 인하여 아래와 같은 방식으로 소유권을 결정하였다.
| 멤버 | 퀴즈 | |
| 소유할 테이블 | 사용자 응답 | 댓글, 좋아요 |
| 해당 사유 | 사용 용도에 의해 멤버의 소멸에 따라 사라지는 것이 자연스러움 | 멤버의 소멸과 상관없이 퀴즈에 따라 만들어져 있어야 하기 때문에 퀴즈의 소멸에 따라가는 것이 자연스러움 |
위의 사항에서 공통적으로 고려한 사항이 더 있다. 바로 서비스 방향의 결정이다. 퀴즈와 멤버를 독립한다는 것은 멤버의 소멸과 퀴즈의 소멸이 서로 관계를 주지 않는 것이다. 즉, 멤버가 탈퇴해도 해당 멤버가 만든 컨텐츠는 유지되는 것을 원하기 때문에 그 방향으로 서비스를 잡았다. 그러나 멤버가 자신의 선택에 따라 삭제를 가능하게 만들어 여지를 남겨두었기 때문에 서로를 독립시키는 것이 맞다는 생각을 했다.
'Spring' 카테고리의 다른 글
| 트러블 슈팅 - 중복 저장 문제 (0) | 2023.11.06 |
|---|---|
| 항해 99 - 트러블 슈팅 Optional(Likes) (1) | 2023.10.25 |
| 항해 99 실전 프로젝트 - 트러블 (Optional) (0) | 2023.10.19 |
| 항해 99 실전 프로젝트 - 문제발생 및 해결 (0) | 2023.10.16 |
| 항해 99 실전 프로젝트 - CRUD (0) | 2023.10.09 |
