데이터베이스

MongoDB 스키마 설계

<aside> 💡

출석 기록을 어떻게 저장할 것인가?

처음에는 수업 컬렉션에 배열을 만들어 학생 컬렉션에서 참조하도록 설계하였다.

그러나 특정 쿼리(학생이 자신의 모든 출석 기록을 조회하고자 하는 경우 등)에서 매우 비효율적일 것으로 예상하였다. → 이러한 경우 모든 수업을 하나하나 조회해야 한다.

따라서 출석 기록을 저장하는 Entry 컬렉션을 별도로 생성하고, 그 안에서 학생과 수업 정보를 참조하도록 하였다.

수업에 대한 출석 기록 조회 쿼리의 경우 이전 방식이 빠르고 간편하지만, 학생과 수업 두 가지 매개에 대한 일관된 필터링과 인덱스 활용 측면에서 더 효과적이다.

또한, 수업 정보와 출석 정보가 분리되어 더 깔끔한 스키마를 작성할 수 있다.

</aside>

MongoDB 의 _id 필드를 활용해보고자 고민하였다.

MongoDB 는 NoSQL 이기 때문에 Join 개념이 없지만, 데이터 모델링 과정에서 분명히 다른 값을 참조해야 할 필요를 느꼈다.

이 프로젝트의 경우 수업 컬렉션에 참여 학생 목록이 포함되어야 하는데, 배열에 정적인 값을 넣는 것 보다는 학생 컬렉션에서 값을 참조하여 무결성을 보장하는 것이 유리하다.

수업 컬렉션에 Ref 배열을 생성하지 않고 별도로 Entry 컬렉션을 만들어 학생과 수업 컬렉션을 참조하였다.

스키마가 다소 복잡해지는 단점이 있지만 MongoDB 의 _id 필드를 효율적으로 활용할 수 있다.

<aside> 💡

참조 문서가 삭제된다면?

SQL 에서는 외래 키의 Cascade 조건으로 참조된 튜플이 삭제되면 관련 데이터들도 함께 삭제되도록 동작할 수 있었다.

반면 MongoDB 의 경우 관련된 문서를 삭제하지 않고 null 로 표시한다.

이런 경우 SQL 이 좀 더 유리하지만, 이 프로젝트에서 데이터 삭제로 인한 무결성 문제는 없거나 미미할 것으로 판단하였다.

</aside>