데이터베이스 구조 화 | Firebase 실시간 데이터베이스 
 데이터베이스 구조 화 
 이 가이드 에서 는 Firebase 실시간 데이터베이스 의 JSON 데이터 구조 화 와 관련 된 주요 데이터 아키텍처 개념 과 몇 가지 권장 사항 을 설명 합니다 . 
 데이터베이스 를 적절히 구조 화 하 려면 철저 한 사전 준비 가 필요 합니다 . 가장 중요 한 것 은 최대한 쉽 게 데이터 를 저장 하 고 이후 에 검색 할 방법 에 대해 계획 을 세우 는 것 입니다 . 
 데이터 를 구조 화 하 는 방법 : JSON 트리 
 모든 Firebase 실시간 데이터베이스 데이터 는 JSON 객체 로 저장 됩니다 . 데이터베이스 를 클라우드 호스팅 JSON 트리 라고 생각 하 면 됩니다 . SQL 데이터베이스 와 달리 테이블 이나 레코드 가 없 으며 , JSON 트리 에 추가 된 데이터 는 연결 된 키 를 갖 는 기존 JSON 구조 의 노드 가 됩니다 . 사용자 ID 또는 의미 를 가진 이름 과 같 은 고유 키로 직접 지정 할 수 도 있 고 , push ( ) 를 사용 하 여 자동 으로 지정 할 수 도 있 습니다 . 
 키 를 직접 만드 는 경우 키 는 UTF - 8 로 인코딩 되 어야 하 고 768 바이트 이하 여야 하 며 . , $, #, [ , ], / , ASCII 제어 문자 0 ~ 31 이나 127 을 포함 할 수 없 습니다 . 값 자체 에 도 ASCII 제어 문자 를 사용 할 수 없 습니다 . 
 예 를 들 어 사용 자 가 기본 적 인 프로필 과 연락처 목록 을 저장 할 수 있 는 채팅 애플리케이션 을 가정 해 보 겠 습니다 . 사용자 프로필 은 일반 적 으로 / users / $ uid 와 같 은 경로 에 위치 합니다 . 사용자 alovelace 의 데이터베이스 항목 은 다음 과 같이 표시 됩니다 . 
 데이터베이스 는 JSON 트리 를 사용 하 지만 데이터베이스 에 저장 되 는 데이터 는 사용 가능 한 JSON 유형 에 대응 하 는 특정 한 기본 유형 으로 표현 하 여 코드 를 보다 쉽 게 관리 할 수 있 습니다 . 
 데이터 구조 권장 사항 
 데이터 중첩 배제 
 Firebase 실시간 데이터베이스 는 최대 32 단계 의 데이터 중첩 을 허용 하 므로 중첩 을 기본 구조 로 도입 해도 괜찮 다고 생각 할 수 도 있 습니다 . 그러나 데이터베이스 의 특정 위치 에서 데이터 를 가져오 면 모든 하위 노드 가 함께 검색 됩니다 . 또한 사용 자 에게 데이터베이스 의 특정 노드 에 대한 읽 기 또는 쓰 기 권한 을 부여 하 면 해당 노드 에 속한 모든 데이터 에 대한 권한 이 함께 부여 됩니다 . 따라서 실제 구현 에서 는 데이터 구조 를 최대한 평면 화 하 는 것 이 좋 습니다 . 
 다음 은 데이터 중첩 을 배제 해야 하 는 이유 를 보여 주 는 다중 첩 구조 의 예 입니다 . 
 이 중첩 설계 에서 는 전체 데이터 를 반복 하 는 것 이 어렵 습니다 . 예 를 들 어 채팅 대화 제목 을 나열 하 려면 모든 멤버 와 메시지 를 포함 한 전체 chats 트리 를 클라이언트 에 다운로드 해야 합니다 . 
 데이터 구조 평면 화 
 비 정규 화 를 통해 데이터 를 서로 다른 경로 로 분할 하 면 필요 에 따라 별도 의 호출 을 통해 효율 적 으로 다운로드 할 수 있 습니다 . 아래 의 평면 화 된 구조 를 살펴보 세요 . 
 이제 대화 당 몇 바이트 만 다운로드 하 여 대화방 목록 전체 를 반복 하 면서 메타데이터 를 빠르 게 가져와서 UI 에 대화방 을 나열 하 거나 표시 할 수 있 습니다 . 메시지 가 도착 하 면 별도 로 가져와서 표시 할 수 있 으므로 UI 가 빠른 반응 속도 를 유지 합니다 . 
 확장 가능 한 데이터 만들 기 
 앱 을 개발 할 때 는 목록 의 일부 만 다운로드 하 는 것 이 나 을 때 가 많 습니다 . 목록 에 수천 개 의 레코드 가 포함 된 경우 에 특히 그러 합니다 . 데이터 의 관계 가 정적 이 며 일방 적 인 경우 에 는 상위 객체 아래 에 하위 객체 를 중첩 하 면 간단히 해결 됩니다 . 
 경우 에 따라서 는 관계 가 동적 이 거나 데이터 를 비 정규 화 해야 할 수 있 습니다 . 대체 적 으로 쿼리 를 사용 하 여 데이터 의 일부 를 검색 하 면 데이터 를 비 정규 화 할 수 있 습니다 . 자세 한 내용 은 데이터 검색 을 참조 하 세요 . 
 이 방법 도 충분 하 지 않 을 수 있 습니다 . 사용자 와 그룹 간 의 양방향 관계 를 예 로 들 수 있 습니다 . 사용자 는 그룹 에 속할 수 있 으며 , 그룹 은 사용 자 의 목록 으로 구성 됩니다 . 이때 사용 자 가 어떠 한 그룹 에 속 할지 를 결정 하 려면 문제 가 다소 복잡 해집니다 . 
 이러 한 경우 특정 사용 자 가 속하 는 그룹 을 나열 하 고 해당 그룹 의 데이터 만 가져오 는 깔끔 한 방법 이 필요 합니다 . 이때 그룹 색인 이 상당 한 도움 이 될 수 있 습니다 . 
 위 와 같이 Ada 의 레코드 와 그룹 모두 에 관계 를 저장 하 면 일부 데이터 가 중복 됨 을 알 수 있 습니다 . alovelace 는 그룹 아래 에 색인 화 되 었 고 techpioneers 는 Ada 의 프로필 에 나열 되 었 습니다 . 따라서 Ada 를 그룹 에서 삭제 하 려면 두 위치 에서 업데이트 가 이루어져야 합니다 . 
 이러 한 중복 성 은 양방향 관계 에서 불가피 합니다 . 사용 자 또는 그룹 목록 이 수백만 개 로 늘어나 거나 실시간 데이터베이스 보안 규칙 으로 인해 일부 레코드 에 액세스 할 수 없 더라도 이 중복 성 덕분 에 Ada 의 소속 그룹 을 빠르 고 효율 적 으로 확인 할 수 있 습니다 . 
 이 와 같이 ID 를 키 로 나열 하 고 값 을 true 로 설정 하 여 데이터 를 반전 하 는 방식 을 사용 하 면 키 를 확인 할 때 / users / $ uid / groups / $ group _ id 를 읽 어서 null 인지 만 확인 하 면 되 니 간단 합니다 . 색인 은 데이터 쿼리 또는 검색 보다 속도 가 빠르 고 훨씬 효율 적 입니다 .