NoSQL의 특징
Firestore는 NoSQL 데이터베이스이기 때문에 RDB처럼 Pk, Fk와 같은 개념이 없다.
대신 데이터를 저장하는 방식과 구조에 따라 관계를 표현해야 한다.
명언 앱을 예로 들자면, 명언 카테고리(quote category)와 명언(quote)의 관계를 Firestore에 저장하는 방법에는 크게 두 가지가 있으며, 각각의 장단점이 있다.
1. 명언 카테고리 문서에 하위 컬렉션으로 명언 저장
구조: quote_category 컬렉션의 각 카테고리 문서 아래에 quotes 하위 컬렉션을 두고 명언을 저장한다.
quote_category (컬렉션)
|- category 문서 (id: "inspiration", name: "영감")
|- quotes (하위 컬렉션)
|- quote 문서 (id: "q1", content: "노력은 배신하지 않는다")
|- quote 문서 (id: "q2", content: "창의력은 곧 자유다")
|- category 문서 (id: "happiness", name: "행복")
|- quotes (하위 컬렉션)
|- quote 문서 (id: "q3", content: "행복은 마음먹기에 달렸다")
장점
-
명언과 카테고리가 잘 그룹화되어 있어서 카테고리별 명언을 조회하기 쉽다.
ex) 특정 카테고리의 모든 명언을 가져올 때 효과적임. -
데이터를 논리적으로 묶을 수 있다.
-
카테고리를 삭제하면 그 하위에 있는 명언 컬렉션도 함께 삭제되므로 데이터 정합성 유지가 간단하다.
단점
-
특정 명언을 전체 조회하거나 검색하기 어렵다. 모든 quote_category 컬렉션의 하위 quotes를 순회해야 합니다.
-
특정 명언이 여러 카테고리에 속해야 할 경우 데이터 중복이 발생한다.
-
쿼리의 깊이가 깊어질 수 있어 복잡도가 증가할 수 있다.
2. 명언과 카테고리를 별도의 컬렉션에 저장하고 FK(유사 관계)를 사용
구조: quote_category 컬렉션과 quotes 컬렉션을 각각 독립적으로 만들고, 명언 문서에 카테고리 ID를 FK처럼 저장한다.
quote_category (컬렉션)
|- category 문서 (id: "inspiration", name: "영감")
|- category 문서 (id: "happiness", name: "행복")
quotes (컬렉션)
|- quote 문서 (id: "q1", content: "노력은 배신하지 않는다", categoryId: "inspiration")
|- quote 문서 (id: "q2", content: "창의력은 곧 자유다", categoryId: "inspiration")
|- quote 문서 (id: "q3", content: "행복은 마음먹기에 달렸다", categoryId: "happiness")
장점
- 모든 명언을 한 번에 조회하거나 검색하기가 쉽다.
예: "전체 명언 중 '노력'이 포함된 명언을 찾기" - 특정 명언이 여러 카테고리에 속해야 할 경우, 데이터 중복 없이 표현이 가능하다.
- 카테고리와 명언을 별도로 관리하기 때문에 구조가 유연하다.
단점
- 특정 카테고리의 명언을 가져오려면 categoryId를 기준으로 필터링 쿼리를 실행해야 하기 때문에 다소 복잡하다.
예: where("categoryId", "==", "inspiration") - 명언과 카테고리 사이의 데이터 정합성을 보장하기 어렵다.
예: 카테고리 문서를 삭제했는데, 해당 카테고리 ID를 참조하는 명언들이 남아있을 수 있다. - 데이터 구조가 논리적으로 느슨해져서 명확하게 연결 관계를 이해하기 비교적 어렵다.
결론: 선택 기준
앱이 단순하다면 1번 방식이 더 직관적이고 관리하기 편하다.
ex) 게시글 - 댓글, 채팅방 - 메시지, Course - Lessons
관리해야 할 데이터가 복잡해질 것 같으면 2번 방식이 관리하기 편하다.
ex) SNS 앱 (Users-Posts-Likes), 도서관리 앱 (Books - Authors), 전자상거래 앱 (Products-Categories)
