목차

ER 다이어그램 결과물

[노란색 표시] Foregin key

[노란색 표시] Foregin key

🤔 고민했던 부분

유저가 즐겨찾기를 해놓은 아카이브들을 조회하는 기능을 구현할 때, 발생한 고민이다.

즐겨찾기 페이지

즐겨찾기 페이지

위 화면에서는 즐겨찾기(Bookmark)한 Archive의 title 과 description, Archive의 owner의 nickname, 그리고 해당 archive에 참여하고 있는 member들의 avatar_id 등의 데이터가 필요하다. 처음 설계한 ERD 상으로는 이러한 데이터들을 가져오기 위해 Bookmark 테이블을 Archive 테이블, Friend 테이블과 Join한 후, User 테이블과 Join을 해야 했다. ArchiveMember 테이블도 이와 마찬가지로 총 5개의 테이블을 Join해야 했다.

SELECT *
FROM Friend f
JOIN User u ON u.user_id = f.user_id # Friend의 User의 nickname
JOIN Bookmark b ON b.friend_id = f.friend_id  # Bookmark한 Archive들을 갖고 오기 위해 join
JOIN Archive a ON b.archive_id = a.archive_id # Bookmark한 Archive의 정보 갖고 오기 위해 join
JOIN ArchiveMember am ON am.archive_id = a.archive_id # Archive 별 Member들을 갖고 오기 위해 join
JOIN Friend f2 ON f2.friend_id = am.friend_id # 멤버별 avatar_id를 갖고 오기 위해 join
JOIN User u2 ON u2.user_id = f2.user_id # ArchiveMember들의 avatar_id를 갖고 오기
WHERE f.user_id = "서버로 요청을 보낸 사용자";

데이터가 많아 질수록 Join 쿼리의 비용은 높아지므로, Join을 줄여보고자 다음과 같은 질문을 던져보았다.

<aside> ❓ User의 nickname 때문에 User와 Friend가 조인해야 한다면… Bookmark 테이블에 User의 nickname도 같이 저장하면 되지 않을까?

</aside>

위 질문에 내린 결론은 “당장은 편할 수 있다.” 이다.

하지만 확장성 관점에서 바라본다면, 좋지 않은 행동이라는 생각이 들었다.