Firestore 데이터 구조 선택

파이어베이스를 이용해서 DB를 관리하고 있는데, 어떤식으로 구조를 작성해서 CRUD에 문제가 없게할 지 실제 고민 및 테스트를 많이 했다.

결과적으로

이런 식으로

collection - document - collection - document… 이렇게 이어서 저장을 했다.

이유

1. status 업데이트 관련해서 처음에는 첫 document의 friends에 배열로 모든 데이터를 관리했는데, 배열 속의 status를 update를 시킬 수 없었기 때문에, 이런식으로 하나의 키로만 갖고있게끔 해서 update를 진행했다.

Q. 그러면 friends를 맵으로만들면 되지않나?
   A. 맵으로 만들었을 때 get으로 받았을 때 내부 friends라는 키를 찾고 
   그 안의 특정 status만을 setdata로 하기에 구조가 굉장히 지저분했기 때문에 위와 같은 방식으로 구조를 짰다.
   

2. collection (”Rooms”).documnet(id)에서 friends를 왜 나눠서 하나는 document, 하나는 collection으로 했는지?

A. RoomsVC에서 각 방들의 인원 정보를 얻을 때 Collection(”Friends”)로 가져오려고하면 방 리스트를 불러오고 
그에 대한 for문을 돌고 해당 documentID마다 for문을 또 돌면서 각각의 인원 정보들을 받아와야했는데, 
그렇게되면 이중 for문을 돌 뿐만 아니라, 비동기로 rooms를 받아오는 것 안에서 또 비동기로 friends에 대한 데이터를 받아와야하기 때문에, 
두개에 대한 비동기를 동기적으로 받아오게하고 또 이것들을 completion으로 정리해서 넘기는게 되지 않았다. 
그래서 collection(”Friends”)에 있는 정보들을 나눠서 화면에 표시하는 것들은 rooms의 friends에 넣어놓고 
나머지는 collection(”Friends”)에서 저장했다.