계획대로라면 서비스를 이전하는 데 문제가 없을 것 같지만 항상 문제는 생기기 마련입니다. 미처 생각하지 못했던 문제가 있지는 않은지 검증하기 위해서 웹사이트를 먼저 Firebase 기반으로 이전해보기로 했습니다. 그 첫 단계로 이전에 관계형 데이터베이스(RDB)에 저장했던 데이터를 Firestore에 어떻게 저장했는지 살펴보겠습니다.

🔗 기존 스키마 살펴보기

erDiagram
  School ||--o{ Semester : ""
  School {
		string id PK
		string name
  }
	Semester {
		string id PK
		string school_id FK
		integer year
		string term
		json periods
    string lectures_url
	}
  User ||--o{ Timetable : has
	User {
		uuid id PK
		string username
		string password
    datetime created_at
    datetime updated_at
	}
	Timetable ||--o{ Lecture : contains
  Timetable }o..|| Semester : ""
  Timetable {
		uuid id PK
		string title
		uuid user_id FK
		uuid semester_id FK
    datetime created_at
    datetime updated_at
  }
  Lecture ||--o{ LectureTime : contains
  Lecture {
		uuid id PK
		string identifier
		string title
		string professor
		decimal credit
		json category
		uuid timetable_id FK
    datetime created_at
    datetime updated_at
	}
  LectureTime {
		uuid id PK
		integer weekday "0:월요일 - 6:일요일"
		integer time_begin "540:9am"
		integer time_end
		string room
		uuid lecture_id FK
    datetime created_at
    datetime updated_at
  }

중심이 되는 테이블은 Timetable입니다. User는 여러 Timetable을 만들 수 있고, Timetable에 여러 Lecture를 추가할 수 있습니다. 그리고 다시 Lecture는 여러 LectureTime으로 구성돼있습니다.

아래는 시간표 하나를 저장하고 있는 테이블들을 나타낸 예시입니다. 몇몇 필드는 생략했고, UUID는 너무 길어서 축약했습니다.

크게 달라진 부분은 없지만 Firestore의 구조에 알맞게 몇몇 부분을 변경했습니다. 눈여겨 볼만한 부분을 살펴볼까요?

• 이제는 Lecture 문서가 Timetable 문서 하위에 있기 때문에 timetable_id를 가리키는 필드는 더이상 필요하지 않습니다. 마찬가지로 Timetable 문서는 User 문서 하위에 있기 때문에 user_id를 가리키는 필드도 필요하지 않습니다.

• 강의시간 정보를 별도의 (LectureTime)컬렉션 대신 Lectue 문서 필드의 값으로 저장합니다.

  → 강의정보 없이 강의시간 정보만 따로 불러올 일이 없는 상황에서 Firestore는 문서 접근에 따른 요금 부과 체계가 있기 때문에 별도 문서로 저장하기보다는 복합 객체 값으로 저장하도록 했습니다.

• 참고로 Lecture 문서의 category, times 필드는 JSON이 아닌 복합 객체 타입입니다.

• username의 고유성을 보장하기 위해 Username Index 컬렉션(/indices/user/usernames)을 새로 만들었습니다.

  RDB와 달리 Firestore에서는 특정 필드에 고유 제약조건을 걸 수 없어 다른 방법을 이용해야합니다. Firestore의 특정 컬렉션 내에서 문서 ID는 고유합니다. 이러한 특성을 이용하기 위해서 별도의 username 컬렉션을 만듭니다. 이 컬렉션과 트랜잭션을 사용해서 username의 고유성을 유지하면서 User를 생성하거나 변경할 수 있고, 보안 규칙을 사용해서 이를 강제할 수 있습니다. 보안 규칙에 대한 내용은 후속편에서 다뤄보겠습니다.

• User의 인증 정보는 이제 별개의 서비스(Firebase Authentication)에서 관리하기 때문에 password 해시를 여기서 저장하지 않습니다.

이제 웹사이트를 옮겨 볼 준비를 마쳤습니다. 다음 글에서는 웹사이트가 기존 서버에 HTTP 요청을 날리는 대신 Firestore SDK를 사용해도록 변경해보고 문제없이 작동하는지 확인해보도록 하겠습니다.