[React Native] - "치열한 하루" 모바일 앱 개발 #2

 

데이터 모델링

백엔드를 맡았다 보니 데이터 모델링을 담당해야 했다. 지금까지 클론 코딩용 데이터 모델링은 해봤지만 실제 서비스의 데이터 모델링은 처음이어서 설레고 재미있었다. 복잡한 데이터 모델이 필요하지 않았고 비교적 다루기 쉬운 서버리스와 NoSQL의 특징을 모두 가지고 있는 Firestore을 사용했기에 실제 서비스의 데이터 모델링을 처음 경험하기에 이번 프로젝트는 최적이었다.

 

 

 Firestore의 데이터 모델

 

공식문서에 따르면 SQL처럼 테이블이나 행이 없으며, 컬렉션(Collection)으로 정리되는 문서(Document)에 Key-Value 쌍으로 이루어진 데이터들을 저장하는 방식이라고 한다. 쉽게 말해, 아래 그림과 같이 한 컬렉션에 여러 개의 문서가 저장될 수 있고 각 문서 안에 데이터 필드와 값들이 존재하는 방식이다.

출처: https://firebase.google.com/docs/firestore#how_does_it_work

 

 

"치열한 하루" 데이터 모델링

 

"치열한 하루" 데이터 모델

 

 

컬렉션은 이 앱을 사용하는 사용자를 식별할 수 있는 값이 담당해야 했다. 하지만, 이 앱은 회원가입이 없기 때문에 ID/PWD가 아닌 식별자가 필요했다. 따라서, 사용자의 기기로 식별할 수 있지 않을까 해서 구글링을 해보니 iOS에서는 UDID(Unique Device Identifier)라는 기기 고유 식별자가 존재한다는 사실을 알 수 있었다. 하지만, 애플의 개인정보보호 정책 때문에 UDID 값은 쓸 수 없었다. UDID를 대체할 값을 찾아보니 IDFA와 IDFV가 있다고 한다. IDFA는 Apple이 운영하는 광고 식별자이고, IDFV는 벤더 식별자라고 한다. 구글링을 해보니 react-native-device-info라는 라이브러리에서 IDFV 값을 제공해준다는 것을 찾을 수 있었다. 따라서 컬렉션은 IDFV 값으로 정했다.

* IDFA는 iOS14 이후부터는 사용자에게 권한을 받아야 사용할 수 있는 것으로 정책이 바뀌었다고 한다.

 

문서는 사용자의 일정을 담당하는 역할로 정했다. 즉, 하나의 문서가 하나의 일정을 의미한다. 따라서 일정끼리의 구별을 위한 문서 ID값이 필요했다. 처음에는 문서 ID값을 Date.now() 메소드의 반환 값을 사용했다. Date.now() 메소드는 UTC 기준으로 1970년 1월 1일 0시 0분 0초부터 현재까지 경과된 밀리 초(ex. 1635748753100)를 반환하는데 JavaScript에서 랜덤 값으로 Unique ID를 사용할 때 자주 쓴다고 한다. 하지만, 이렇게 하면 데이터베이스를 관리하기 쉽지 않았다. 한눈에 어떤 일정의 문서인지 알고 싶기에 문서 ID를 바꿀 필요가 있었다.

 

문서 ID를 새로 정할 때 두 가지를 고려했다. 첫 번째로는, 일정과 관련된 정보를 담고 있어야 한다. 그래야 명시적으로 보일 수 있기 때문이다. 두 번째로는, Firestore는 문서 ID를 오름차순이나 내림차순으로 정렬되게 설정해줄 수 있는 데 이러한 정렬이 의미가 있어야 한다. 이 두 가지 사항에 모두 부합하는 것이 바로 일정의 시작 시간이다. 각 일정들의 시작 시간에 따라 오름차순 정렬을 시키면 시간 순서대로 데이터가 관리되어서 관리하기 한층 편해진다.  또한, 해당 데이터들을 가져와 사용할 때 수동으로 시간 순서대로 정렬을 하지 않아도 돼서 편리해진다. 최종적으로 "YYYYMMDDHH:MM"형식의 시작 시간을 문서 ID로 정했다. 결과적으로 더 많은 시간 정보를 내포하고 있어서 더욱더 관리하기 쉬워졌다.

 

데이터는 일정의 제목, 날짜, 시작과 끝 시간 / 일정 장소의 장소명, 주소, 위도 , 경도 / 일정의 체크 리스트 / 문서 ID / isDone / isSkip으로 구성되어있다. isDone은 사용자가 일정 장소에 도착해서 일정을 완료한 일정인지 아닌지 나타내는 Boolean 데이터다. isSkip 또한 해당 일정이 스킵한 일정인지 아닌 일정인지 나타내는 Boolean 데이터다.

 

 

실제 데이터 모델 예시