내부DB -> Firebase로 마이그레이션하는 과정에서..

개인 프로젝트 개발하는 과정에서 데이터베이스를 바꾸고자 했다.

맨 처음엔 UserDefaults를 사용했다가, SQLite3로 변경했었다.

SQLite3로 변경한 이유는 범용성이 뛰어나기 때문에 알아두기 위해 사용했다.

내부DB 특성상 앱이 삭제되면 데이터도 같이 삭제되기 때문에 안정성이 떨어지긴하다.

그래서 외부DB로 바꾸고자 한다.

 

RandomStudy의 데이터 모델 변천사

이 프로젝트의 데이터모델은 총 세가지였다.

이에 따라 데이터 모델도 세개로 구현했지만, 찝찝한 마음이 있었다.

데이터 흐름이나 모델의 공통적인 변수들만 봐도 굳이 세개로 구현해야할까? 느꼈다.

UserDefaults로 구현했을 때 세개의 데이터모델을 사용했고,

SQLite로 변경하면서 데이터의 모델이 다르면 번거롭게 호출수가 많아질 듯 하여 데이터 모델을 통합시켰다.

 

 

SQLite3로 변경할 때 데이터모델도 통합시켰다.

할일을 저장하고, 불러오고 완료하는 데이터 흐름은 동일하다.

하지만 할일 데이터모델에서 done, date 변수는 필요가 없었고, 오늘의 할 일에선 date가 필요하지않았다.

그래서 임의의 값을 넣어두고, 데이터가 넘어갈때 추가하는 형식을 이용했다.

 

이게 맞는지 의심이 되는데, 외부DB로 변경할 때 문제점이 드러났다.

 

데이터베이스에는 원칙이 있다.

• 무결성
• 안정성
• 확장성

Firebase로 마이그레이션 하고나니 데이터베이스의 무결성 원칙을 위배하는 것이다.

 

할 일을 저장한 study

오늘의 할일을 저장한 todo를 보면 아예 같은 값이 저장되있는것을 볼 수 있다.

체크를 한다면 done이 1로 변경되어 다른값으로 되지만, 다른 관점으로 보자.

 

1. 서버로부터 데이터를 호출할 때

서로 다른 테이블이지만 값이 같다. 할 일과 오늘의 할일에 저장된 데이터를 부르기위해 두번의 호출을 해야한다.

값이 같은 데이터를 두번에 걸쳐서 호출한다는 것은 효율적인 방법일까?

이는 데이터가 많으면 많아질수록 더욱 더 효율성이 떨어진다.

 

2. 데이터 모델을 통합하지 않는다면?

데이터 모델을 통합하지 않는다면 데이터베이스도 서로 다른 데이터모델을 저장할 공간이 필요하고, 서버도 많은 모델을 전송해야 하기에

이는 효율적이지 않다고 생각한다.

 

위 두가지를 고려하여 데이터 구조를 설계 하고자 한다.

JSON파일이 들어왔을때, 데이터를 사용하려면 디코딩과정이 필요하다.

JSON의 데이터중 원하는 데이터는 데이터모델로 구현하지만,

해당 데이터가 존재하지 않는다면, 옵셔널로 지정하지 않으면 오류가 발생한다.

 

위의 데이터 모델을 무결성을 위배하지 않고, 한번의 호출로 데이터를 분리하기 위해 데이터모델을 다음과 같이 구현한다.

 

struct DataModel{
    let name: String
    let done: Bool?
    let date: Date?
}

 

이렇게 데이터 모델을 구현하고, 필터링은 값이 존재하는지 판단후 분리하기로 한다.

이렇게되면 데이터는 한번만 호출하고, 필터링을 거쳐서 세가지로 분리된다.

• 데이터 한번 호출
• 서버가 필터링
• 앱은 데이터받기

앱이 데이터 받고 필터링한다면 사용자가 데이터 호출을 했을 때, 보여지는 시간까지 지연될 수 있어서 보통 서버가 해주지만,

지금은 없는 관계로 앱이 데이터를 받고 필터링을 해보자.

 

이전에 데이터를 데이터모델 수만큼 호출하여 불러왔다면,

데이터를 한번 불러오고, VC에 맞춰서 분리한 모습이다.

 

데이터를 받아오는 시간이 길어진다면 사용자가 확인하는 시간이 그만큼 지연되므로 데이터늘 받아오는 횟수는 최소로 줄이고자 해야겠다.