本人是mongoDB新手,看过了官网上关于嵌入式非规范化数据库的介绍,但是面对实例的时候仍然是一头雾水.(官网上面的实例只有两三个collection,感觉比实际应用简单太多)
每年一个赛季,一个联赛对应多只队伍,每个队伍有多名队员.队员属性有身高体重所属球队球衣号码场上位置(队员有可能转会,但某一特定时间只属于一个球队).联赛有常规赛,季后赛之分,每场比赛有主/客队,需要记录下每个上场队员的得分/篮板/助攻/盖帽/抢断以及每一个事件的时间戳.每场比赛对应多个新闻报道文章
典型应用场景:
最新10场比赛的主/客队得分,胜负
所有球队的积分排名
所有球队在本赛季的平均得分/篮板/助攻/盖帽/抢断 前10名排行榜
所有球员在本赛季的平均得分/篮板/助攻/盖帽/抢断 前10名排行榜
某场比赛中主客队球队本场比赛的得分篮板助攻命中率等
某场比赛中主客队球员在本场比赛的得分篮板助攻命中率等
所有球员在某个赛季中的各项数据排行
某个球员在各个赛季中的平均各项数据(转会过的球员有可能在不同球队)
可否给出一完整的数据模型结构设计,万分感谢!
一些想不明白的问题:
是否应该把球员嵌入到球队中?如何处理转会问题?
是否应该把每场比赛的数据嵌入到每场比赛中?如果是,又如何关联球员与每一次得分/..事件的关系?
在哪里非规范化数据,感觉不管怎么设计,在汇总球队,或者球员的历史数据的时候,和做排名的时候,都要扫描整个数据库,这不科学吧...
在哪里做索引可以显著的提高性能?
这个应用场景到底合适不合适用nosql.................
PHP中文网2017-04-25 09:06:40
大原則は、アクセス パターンに基づいて設計することです。幸いなことに、典型的なアプリケーション シナリオがすでにあります。
チームとプレーヤーの間の 1 対多の関係を埋め込むか分離できるかは、主にこれら 2 つのデータが頻繁に一緒に使用されるかどうかによって決まります。併用の例: SegmentFault の質問と回答も 1 対多ですが、一緒に表示されることがよくあります。そうでない場合は、それを分離して、プレーヤーの名前、_id、プレー時間、およびその他の基本情報をチームに追加できます。この種の非正規化では、更新が必要なときに更新する場所がもう 1 つ必要になります。しかし、この情報（異動など）の更新頻度は非常に低く、よく読まれるため、それでも価値があります。
統計。プレイヤーの履歴データを再計算する場合、どのようなデータ インベントリが使用されているかに関係なく、データベース全体を走査する必要がありますよね。これは、読み取りと書き込みの前のもう 1 つのトレードオフです。明らかに、データ更新はクエリよりもはるかに少ないため、統計データをキャッシュすることには意味があります。さらに、特定のシーズンのチームの統計など、一部の統計は一定です。更新する場合、リアルタイムで更新することも、計算に役立つ合計数と回数の平均値などの一部の中間結果をキャッシュすることもできます。あるいは、各試合後に 1 日 1 回更新することも可能です。
各ゲームのデータはゲームとプレイヤーに関連していますが、特定のゲームと同じクエリがよくあるのでしょうか?そうでない場合は、統計サービスに限り、別のコレクションに入れるのもよいでしょう。
インデックスはデータをより速く見つけるのに役立ちますが、結果として得られるデータセットを減らすのには役立ちません。データ モデルを設計した後は、インデックスを選択するのが自然です。
