저는 데이터베이스 작업에 새로운 경험이 있으며 NoSQL과 MySQL의 차이점에 대해 배우고 있습니다. 사용자가 자신의 캘린더에 넣을 이벤트를 만들 수있는 웹 응용 프로그램을 만들고 있습니다.MongoDB 데이터베이스를 어떻게 구성해야합니까?
지금은 사용자 이름과 비밀번호를 수집하고 이벤트를 저장하는 각 사용자의 컬렉션을 보유하고 있습니다. 그러나 NoSQL에 대해 더 많이 읽으면서 모든 이벤트에 대한 콜렉션이 있어야하며 각 사용자의 이벤트를 단일 문서에 저장해야합니다. 따라서 데이터베이스에는 사용자 이름과 이벤트를위한 2 개의 콜렉션이 있습니다. 이것은 더 합리적인 것처럼 보이지만 큰 문서를 가진 매우 큰 이벤트 컬렉션으로 끝날 것입니다.
가장 좋은 방법은 무엇입니까? 많은 MongoDB 예제를 살펴 보았지만 대부분 컬렉션이 하나 인 간단한 데이터베이스 만 보여줍니다.
MongoDB의 효과적인 모델링이 그리 명확하지 않습니다. 거의 확실한 응답은 없지만 몇 가지 힌트를 드리겠습니다.
NoSQL 데이터베이스의 일반적인 원칙은 계획중인 요청에 따라 데이터를 모델링하는 것입니다. 모든 이벤트의 목록을 가져와야하는 경우 모든 항목을 고유 한 문서에 저장하는 것이 훨씬 효율적입니다. 특정 사용자에 대한 모든 문서 목록을 가져와야하는 경우 사용자를 설명하는 문서에 이벤트 목록을 저장하는 등의 작업을 수행 할 수 있습니다. 이로 인해 일부 데이터가 복제 될 수 있습니다. 각 사용자 문서에는 모든 이벤트 목록과 이벤트 목록이 모두있을 수 있습니다.
그런 다음 일반적인 딜레마가 있습니다. 사용자를 설명하는 각 문서에 다른 이벤트에 대한 참조 정보 만 포함하면 다른 문서에 저장됩니다.
다시 한번 요청을하는 방식에 따라 다릅니다. 이벤트를 업데이트해야하는 경우 사용자 문서 (적어도 ID)에 불변 프로퍼티 (일부) 만 삽입하는 것이 좋습니다. 이벤트가 변경 불가능하고이 특정 유스 케이스에있을 가능성이있는 경우 전체 이벤트 설명을 사용자 문서에 포함시킬 수 있습니다. 또는 최소한 사용자를로드 할 때 유용한 이벤트 설명의 모든 필드.
크기를 고려하여 제한 사항은 MongoDB's documentation에 설명되어 있습니다.
NoSQL의 기본 원칙은 내 요청에 따라야한다는 것입니다.하지만 사용자 컬렉션이 예외가 될 것이라고 생각했습니다. 암호, 세션 쿠키 등을 저장하는 경우 –
제 관점에서 보면 위에서 설명한 일반 규칙을 따릅니다. 암호와 세션 데이터를 업데이트해야하므로 복제하지 않는 것이 좋습니다. ==>이를 사용자 문서에 포함시키고이 문서에도 이벤트 목록 (또는 이벤트 ID)을 저장하십시오. –