1. Realtime Database 특징
- Firebase Realtime Database 는 JSON형태의 NoSQL 데이터베이스
- 연결된 모든 클라이언트에 실시간 동기화되는 특징
- 일반적인 SQL 데이터베이스로 구현하는 웹개발과는 다른 특징을 가짐
- NoSQL의 특징을 가지고 있는 데이터베이스로서 데이터베이스 구조를 미리 정의 하지 않습니다. (미리 테이블이나 칼럼을 생성할 필요가 없습니다.)
- NoSQL 데이터베이스지만 실시간 동기화되는 특성으로 인하여, 저장할 데이터 구조는 최대한 중첩을 배제해야합니다.(JSON Object 값에 다시 JSON Object가 중첩이 되는 형태를 말합니다.)
- Firebase Realtime Database와 Node.js를 함께 사용하여 서버에서 로직도 구현이 가능하지만, 클라이언트의 코드에 비즈니스 로직이 모두 들어가 있음. 이로 인해 다른 데이터베이스보다 데이터베이스 권한관리가 중요하며, 데이터 구조에 맞추어 세세하게 권한 및 유효성 검증을 할수 있는 기능이 포함되어 있습니다. 이는 예제 후반부에 다루게 될 것입니다.
- Realtime Database의 경우 데이터베이스 구조를 미리 정의하지 않지만, 계획은 세워야함.
- SQL처럼 미리 테이블과 칼럼을 생성하지 않을 뿐, 데이터가 저장되면서 구조를 가지게 됨
- 어떤 데이터가 저장이 될지 미리 계획을 세우고 있어야 데이터베이스 권한 및 유효성 관리 가능
- 대표적인 NoSQL데이터베이스인 MongoDB 에서는 데이터의 단위를 Collection, Document, Field 등으로 나누지만, Firebase Realtime Database에는 없는 개념
- 오로지
Reference라는 데이터의 특정 위치를 나타내는 객체만 있음 Reference라는 데이터위치를 나타내는 객체를 통해 데이터의 실시간 수신을 위해 특정 위치의 데이터 변화를 읽어드리기 위해 수신대기를 하거나, 해당 위치에 데이터를 쓰게 됨
2. 데이터 베이스 구조
2.1 전체 구조
- Firebase Web 채팅앱 만들기를 구현하기 위한 데이터 구조
- FcmId - Firebase Messaging 을 통해 웹 푸시기능을 구현할때 사용할 유저별 FCM ID값 데이터
- Messages - 채팅방 별 메세지데이터
- RoomUsers - 채팅방 별 유저리스트
- UserRooms -유저별 채팅방 리스트
- Users - 가입한 유저 데이터
- UserConnection - 유저별 접속여부 기록
2.2 세부구조
- FcmId > 유저UID > FCM ID값
- Messages > 채팅방ID > 메세지ID > 메세지 세부데이터(메세지, 프로필이미지, timestamp, 유저UID, 유저이름)
- RoomUsers > 채팅방ID > 유저UID
- UserRooms > 유저UID > 채팅방ID > 채팅방 세부데이터(마지막메세지, 프로필이미지, 채팅방ID, timestamp…)
- Users > 유저UID > 유저 세부데이터 (이메일, 프로필이미지, 유저이름)
- UsersConnection > 유저UID > 접속여부 , 마지막 접속 timestamp
- 최대한 중첩을 배제하였으며, 유저UID로 읽기 및 쓰기 권한을 주기 위하여 위와 같이 데이터구조를 계획
- 위 구조가 정답은 아니며, 다양한 데이터 구조가 나올 수 있을 것입니다.
- 다음 글에서 Firebase Authentication을 활용하여 가입 및 로그인 처리 후 Realtime Database 에 Users 항목에 가입한 유저들의 데이터를 저장을 해봅니다.