34일차

34일차는 작성한 DB설계의 1차 설계를 피드백을 받고, 버전2 설계를 진행했다. 또한 댓글 모달을 얼추 마무리 지을 수 있었다. 이러한 과정에서 많은 걸 배웠고 공부가 되었다.

34일차에 배운 내용을 기록해보자.

DB설계

Firebase는 NoSQL을 제공하는 플렛폼이다. NoSQL에서는 임베디드 방식과 참조 방식이 있고, 이에 대해 알고 있었다. 그러나 이를 어떨 때 사용하는지에 대해 정확하게 알지 못했지만, 이제는 알 수 있게 되었다.

설계한 DB의 일부 예시

임베디드 방식

임베디드 방식은 데이터를 중첩된 형태로 저장하는 방식으로, 하나의 문서 안에 다른 문서를 포함하여 저장하는 방식이다. 중첩 구조를 사용하면 데이터의 복잡성을 줄일 수 있고, 데이터를 한 번에 가져오기 때문에 쿼리 성능이 향상된다는 장점있다. 단점은 반대로 중첩이 깊어지면 복잡해진다.

예시

{
  name: "John Doe",
  age: 30,
  posts: [
    {
      title: "Post 1",
      content: "..."
    },
    {
      title: "Post 2",
      content: "..."
    }
  ]
}

이런 방식으로, posts필드는 값만 갖는게 아니라 하나의 문서가 중첩해 들어와 있다. 이러한 형태를 임베디드 방식이라 한다.

참조방식

데이터 간에 참조를 통해 관계를 설정하는 방식이다. 이 방식은 데이터의 일관성을 유지하고 데이터베이스의 쿼리 크기를 줄이는 데 도움이 된다.

예시

// 사용자 문서
{
  name: "John Doe",
  age: 30
}

// 포스트 문서
{
  title: "Post 1",
  content: "...",
  userId: "user_id_1"
}

포스트 문서에서 userId 필드는 사용자 문서에서 user의 id값을 참조하고 있다. 이러한 방식을 참조 방식이라 한다.

어떨 때 임베디드? 참조?

핵심은 읽여지는 건지, 변경되는건지를 중심으로 생각하면 된다. 임베디드 방식은 데이터가 자주 읽여지는 경우 사용하는 방식이다. 참조 방식은 데이터의 변경이 자주 일어나는 경우 사용된다.

정리하기

34일차는 DB설계에 대해 더욱 공부하는 시간을 가졌다. 이전에는 추측으로 DB를 작성했다면, 이제는 더욱 명확한 근거를 가지고 설계를 할 수 있게 되었다.

DB뿐만 아니라 앞으로 모든 코드를 작성할 때는 추측이 아닌 명확한 근거를 토대로 작성하는 습관을 들여야겠다.

본 후기는 유데미-스나이퍼팩토리 10주 완성 프로젝트캠프 학습 일지 후기로 작성 되었습니다.
#프로젝트캠프 #프로젝트캠프후기 #유데미 #스나이퍼팩토리 #웅진씽크빅 #인사이드아웃 #IT개발캠프 #개발자부트캠프 #리액트 #react #부트캠프 #리액트캠프