데이터베이스에 접근할 수 있는 권한에 대한 보안을 작성해줘야하는데
나중에 설정합시다! (swift로 작성하는 게 아님)
우선은 테스트 모드로 시작하는 걸로~!
저장될 로케이션 설정해주고
Boom
데이터베이스가 만들어졌습니다.
거의 폴더 구조랑 비슷하다고 생각하면 됨
컬렉션에 들어가는 데이터 타입들은 동일하게 맞춰주는 게 좋음
데이터를 요청할 때 편하니까
컬렉션을 시작해봅시다
문서ID는 자동 버튼을 눌러서 생성되게 해주고
필드에 들어가는 이름을 어떻게 해야할지 한번 고민해봐야함!
FireStore에서 여러가지 플랫폼들에서도 접근이 가능하게 하려면
Swift처럼 isHealthy가 아니라 is_healthy 로 작성해줘야 편함!
이렇게 쓰게 되면 나중에 CodingKey 추가해줘야겠죠
이런 필드도 추가해줄 수 있고!
추가로 id 필드 까지 추가해줘야합니다~
유저 콜렉션도 새로 만들어줬는데 authenticated된 유저의 uid를 받아서 여기 id에다가 나중에 넣어주게 됨
요런느낌이 되겠죠
이 유저가 다른 콜렉션을 만들게 된다고 해보자
grocery list를 만든다고 했을 때 이 내용을 fruits 컬렉션에 넣는 건 바람직하지 않음
user랑 연관이 있으니까 user한테 넣어줘야겠죠?
그런데 이렇게 하게 됐을 때 또 문제가 있죠
우리의 Fruits에선
애플이 대문자인데 방금 만든 건 apple 소문자잖음
fetch해서 또 찾아가는 과정이 필요하겠네
그래서 fruits apple의 아이디 값 자체를 저장하는 거!!
이렇게 되면 바로 접근할 수 있겟죠
orange도 id가 저장되게 해주고!!
여기서 만약에 쇼핑해야되는 순서나, 이건 이미 샀다 같은 체크를 해야하는 또 다른 데이터가 연관되게 된다고 해보자
여기에 뭔가 추가하는 게 어렵겠죠?
그래서!! users 콜렉션 안에 user 안에
새로운 콜렉션을 구성해주는겨!!
grocery_list 안에 들어가는 문서를 각각의 과일들로 만들어주게 되면 이 과일들에 또 새로운 필드들을 무궁무진하게 추가해줄 수 있겠죠
여기서 생각해볼 점은 지금 grocery_list의 아이템들에 id랑 fruit_id가 둘다 있음. fruit_id를 그대로 id로 사용해도 되겠지만 이건 개발자에게 달려있다!! fruit이 중복이 될 거냐 안될거냐 에 갈리게됨
이제 중요한 건 fetch를 어떻게 할거냐!
fruits 컬렉션 같은 경우 하위에 컬렉션이 없어서 그냥하면 되는데
지금처럼 users콜렉션의 경우 하위에 새로운 컬렉션이 있다!
이럴 땐 이 콜렉션까지 fetch 한번에 되지가 않음
두번에 걸쳐서 하게 됨
그래도 여러 프로퍼티들을 조합할 수 있어서 하위컬레션 추가하는 이 방법이 더 좋습니다
grocery_list가 여러개일 경우에는 또 다르게 해줘야겠죠
grocery_lists --- (myFirstList:필드, items:콜렉션) --- items콜렉션의 fruit_id
요렇게 또 콜렉션이 중첩되게 됨
또 다르게 해줄 수도 있음!!
아예 밖에다가 빼버리는겨
 |  |
|---|
그러고나서 누가 만들었는지 user_id 같은 걸 필드로 추가해주는 방법으로 가능해집니다!!
