액세스 패턴을 기반으로 설계하는 것이 가장 큰 원칙입니다. 다행히도 이미 일반적인 애플리케이션 시나리오가 있습니다.

1. 팀과 플레이어 간의 일대다 관계는 내장될 수도 있고 분리될 수도 있습니다. 이는 주로 이 두 데이터가 함께 사용되는 빈도에 달려 있습니다. 함께 사용하는 예: SegmentFault의 질문과 답변도 일대다이지만 함께 표시되는 경우가 많습니다. 그렇지 않은 경우 분리하여 플레이어 이름, _id, 플레이 시간 및 기타 기본 정보를 팀에 추가할 수 있습니다. 이러한 종류의 비정규화를 수행하려면 업데이트해야 할 때 업데이트할 위치가 한 군데 더 필요합니다. 그러나 이 정보(예: 전송)의 업데이트 빈도가 매우 낮고 많이 읽혀지기 때문에 여전히 가치가 있습니다.

2. 통계. 플레이어의 과거 데이터를 다시 계산하려면 어떤 데이터 인벤토리를 사용하든 전체 데이터베이스를 순회해야 하지요? 이는 읽고 쓰기 전의 또 다른 절충안입니다. 분명히 데이터 업데이트는 쿼리보다 훨씬 적으므로 통계 데이터를 캐싱하는 것이 의미가 있습니다. 또한 특정 시즌의 팀 통계와 같은 일부 통계는 일정합니다. 업데이트 시 실시간으로 업데이트되거나 총 횟수 및 횟수의 평균값 등 일부 중간 결과를 캐시하여 계산에 도움을 줄 수 있습니다. 또는 각 게임이 끝난 후 하루에 한 번씩 업데이트하는 것도 가능합니다.

3. 각 게임의 데이터는 게임 및 플레이어와 관련이 있지만 특정 데이터로 쿼리되는 경우가 자주 있습니까? 그렇지 않고 통계용으로만 사용된다면 별도의 모음집에 넣어 두는 것도 좋습니다.

4. 색인은 데이터를 더 빠르게 찾는 데 도움이 될 수 있지만 결과 데이터 세트를 줄이는 데는 도움이 되지 않습니다. 데이터 모델을 디자인한 후에는 인덱스를 선택하는 것이 당연합니다.