파이어베이스 Looky 데이터 구조
Looky 프로젝트의 백엔드를 대체하여 파이어베이스를 사용하였다.
파이어베이스에서 Cloud Firestore를 이용하였는데, 구조는 컬렉션을 생성하여 내부에 여러 문서들이 존재하고 문서마다 필드를 추가할 수 있는 형식이었다.
처음 이 클라우드 파이어스토어를 보았을때 컬렉션은 테이블, 여러 문서들은 테이블의 튜플, 그리고 그 문서에 추가할 수 있는 필드들이 속성(Attribute)의 개념을 가지고 있다고 생각을 하고 이에 맞게 초안 데이터베이스의 구조를 짜보았다.
파이어베이스는 RDBMS가 아닌 NOSQL이기 때문에 아래에 짠 구조와 다른 방향의 구조로 만들게되었다.
( RDBMS는 RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스로 즉, 관계형 데이터베이스를 생성하고 수정, 삭제 관리할 수 있는 소프트웨어라고 정의
관계형 데이터베이스(RDMBS)에서는 이러한 관계를 나타내기 위해 외래 키(foreign key)라는 것을 사용
이러한 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다는 게 RDBMS의 가장 큰 특징 )
사실 엄~청 큰 차이는 없다. Looky 프로젝트는 큰 프로젝트가 아니어서 비교적 복잡한 데이터베이스 구조로 이루어져있지 않았기 때문이다.
큰 차이점이라면 Looky 프로젝트의 핵심 기능인 게시물마다의 태그 기능을 만들 때 게시물을 업로드 할 때와 업로드한 게시물을 조회할 때의 태그 위치가 동일하게 위치해 있어야 했기 때문에 " 게시물 " 테이블의 " 태그 " 테이블을 외래키로 묶어서 게시물을 업로드할 때마다 태그를 만들어둔 상태라면 해당 태그 하나하나 마다의 테이블에 저장을 하고 추후 " 게시물 " 조회를 할 때 게시물 테이블의 태그 외래키를 이용해 태그들도 같이 데려올 계획을 했었다.
하지만 이는 결국 NOSQL임을 알고나서 " 게시물 " 컬렉션에 " tags "라는 태그들 마다 좌표, 이름, 가격등의 속성을 가지고 있는 객체 배열 필드를 만들어 데이터를 관리하는 방식으로 변경하였다.
그 다음 차이점은 " 게시물 " 테이블에 " 유저 " 가 작성한 " 댓글 " 이었다. 이 부분 또한 어떤 " 게시물 "의 " 댓글 "인지 , 어떤 " 유저 "가 작성한 " 댓글 "인지에 관하여 조회를 할 경우가 있어야했기 때문에 " 댓글 " 이라는 테이블을 따로 생성한 후 외래키로 " 게시물 "과 " 유저 " 테이블과 연결을 하려했지만 NOSQL임을 알고나서는 ...
파이어베이스가 회원가입시 유저마다 기본적으로 제공하는 사용자 인증 코드인 UID를 이용하였다.
해당 유저가 게시물을 작성시 " 게시물 " 테이블의 댓글 객체 배열 필드를 만들어 그 안에 댓글을 작성한 유저의 UID도 함께 넣어서 추후 어떤 유저가 그 댓글을 작성하였는지 확인할 수 있는 용도로 구조를 짯다.