数据结构 - 如何在MongoDB/NoSQL中设计篮球联赛的数据模型?

Question

本人是mongoDB新手,看过了官网上关于嵌入式非规范化数据库的介绍,但是面对实例的时候仍然是一头雾水.(官网上面的实例只有两三个collection,感觉比实际应用简单太多)
每年一个赛季,一个联赛对应多只队伍,每个队伍有多名队员.队员属性有身高体重所属球队球衣号码场上位置(队员有可能转会,但某一特定时间只属于一个球队).联赛有常规赛,季后赛之分,每场比赛有主/客队,需要记录下每个上场队员的得分/篮板/助攻/盖帽/抢断以及每一个事件的时间戳.每场比赛对应多个新闻报道文章
典型应用场景:
最新10场比赛的主/客队得分,胜负
所有球队的积分排名
所有球队在本赛季的平均得分/篮板/助攻/盖帽/抢断 前10名排行榜
所有球员在本赛季的平均得分/篮板/助攻/盖帽/抢断 前10名排行榜
某场比赛中主客队球队本场比赛的得分篮板助攻命中率等
某场比赛中主客队球员在本场比赛的得分篮板助攻命中率等
所有球员在某个赛季中的各项数据排行
某个球员在各个赛季中的平均各项数据(转会过的球员有可能在不同球队)

可否给出一完整的数据模型结构设计,万分感谢!
一些想不明白的问题:
是否应该把球员嵌入到球队中?如何处理转会问题?
是否应该把每场比赛的数据嵌入到每场比赛中?如果是,又如何关联球员与每一次得分/..事件的关系?
在哪里非规范化数据,感觉不管怎么设计,在汇总球队,或者球员的历史数据的时候,和做排名的时候,都要扫描整个数据库,这不科学吧...
在哪里做索引可以显著的提高性能?

这个应用场景到底合适不合适用nosql.................

Answer 1

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

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

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

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

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