어제 MongoDB 카페에 갔습니다
MongoDB 카페가 열린 건 아니고요
그냥 카페에서 MongoDB 생각을 했습니다
사실 카페에 간 건 아니고요
그냥 집에서 데이터베이스를 관리했습니다.
사실 데이터베이스도 안 관리했습니다
그냥 MongoDB 상태입니다

개요

개인 프로젝트를 진행하는데 속성에 많은 양의 텍스트가 들어가고, 수정 없이 대부분 조회만 할 것 같아서 NoSQL을 사용해보기로 했다. 그 중에서도 참고할만한 레퍼런스가 많고 Document 지향 DB라는 MongoDB를 사용했다.

이전에 쭉 RDB만 사용해와서 NoSQL의 개념은 좀 생소했다.

"어떻게 스키마, 제약조건, 외래키 같은 것들도 없이 DB를 구성할 수 있지?"

처음에는 개념이 잘 이해가지 않았지만 직접 사용하다 보니 점점 감이 잡히기 시작했다.

내가 이해한 바로 NoSQL, 그 중에서도 MongoDB는 이런 특징을 가진 DB라고 아주아주 간단하게 말할 수 있겠다.

1. 형식 필요 없음
2. 그냥 json을 저장한다고 생각해
3. 속도: 빨라질게
4. 사용법 아주 쉬움

물론 아직 사용한지 얼마 안돼서 정확하지 않을 수 있지만 내가 느낀 바로는 이렇다.

전개

내가 만드려는 테이블의 구조는 대충 이랬다.
문제의 질문, 문제의 보기들(문제의 보기 리스트), 문제의 정답

RDB로 구조를 짰다면 연관관계 설정을 하고 어떻게 참조해서 어떻게 했겠지만 NoSQL을 처음 사용하다보니 어떻게, 어디서부터 해야할지 조금 어려웠다.

quiz_obj_mutiple={
        "question": "도커 컨테이너를 생성하기 위해서는 무엇이 필요한가?",
        "options": {
            "1": "도커 이미지",
            "2": "도커 파일",
            "3": "도커 컴포즈",
            "4": "도커 네트워크"
        },
        "answer": "1"
    }

이런 json 객체를 DB에 저장하려고 했다. 여기서 options 내부의 값을 어떻게 지정해줘야 할지 고민 중이었던 찰나....

# DB에 quiz를 저장하는 함수
insert_quiz(quiz_obj_mutiple)

???

???

아묻따 그냥 저장돼버렸다.

생각해보니 이렇게 자세한 형식 없이 DB에 저장하면 문제가 객관식이던 주관식이던 서술형이던 question과 answer만 형식을 갖추면 나머지는 상관 없는게 아닌가???

그래서 해봤다.

"이 시점 이후로 나는 이미 1년 365일 상시숭배 중이었다."

결론

NoSQL은 형식이 자유롭다고 말은 많이 들었는데 실제로 경험해보니 RDB만 썼던 나에겐 실로 놀라운 경험이 아닐 수가 없는 상태가 아닐 수가 없을리가 없게 되었다.

앞으로 DB로 구현해야할 것들이 많을텐데 이번 경험으로 더 유연하게 설계를 할 수 있을 것 같다는 생각이 든다.