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

Question

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

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

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

Answer 1

Le grand principe est de concevoir sur la base d'Access Pattern. Heureusement, nous avons déjà des scénarios d'application typiques.

1. La relation un-à-plusieurs entre l'équipe et le joueur peut être intégrée ou séparée. Cela dépend principalement du fait que ces deux données sont souvent utilisées ensemble. Exemples d'utilisation conjointe : les questions et réponses de SegmentFault sont également un-à-plusieurs, mais sont souvent affichées ensemble. Sinon, vous pouvez le séparer et ajouter le nom du joueur, le _id, le temps de jeu et d'autres informations de base à l'équipe. Ce type de dénormalisation nécessitera un endroit supplémentaire pour être mis à jour lorsqu'il doit être mis à jour. Mais comme la fréquence de mise à jour de ces informations (comme les transferts) est très faible et qu’elles sont beaucoup lues, cela en vaut quand même la peine.

2. Statistiques. Si vous recalculez les données historiques d'un joueur, quel que soit l'inventaire de données utilisé, vous devez parcourir l'intégralité de la base de données, n'est-ce pas ? C'est un autre compromis avant de lire et d'écrire. Évidemment, les mises à jour des données sont bien moindres que les requêtes, la mise en cache des données statistiques est donc significative. De plus, certaines statistiques sont constantes, comme celles d'une équipe sur une saison donnée. Lors de la mise à jour, il peut être mis à jour en temps réel, ou certains résultats intermédiaires peuvent être mis en cache, tels que la valeur moyenne du nombre total et des fois pour faciliter les calculs. Alternativement, une mise à jour une fois par jour après chaque jeu est une possibilité.

3. Les données de chaque jeu sont liées au jeu et aux joueurs, mais sont-elles souvent interrogées auprès d'un certain ? Dans le cas contraire, mais uniquement pour les services statistiques, il est également bon de les placer dans une collection séparée.

4. Les indices peuvent vous aider à trouver des données plus rapidement, mais ils ne peuvent pas vous aider à réduire l'ensemble de données résultant. Une fois le modèle de données conçu, il est naturel de choisir un index.