本人是mongoDB新手,看過了官網上關於嵌入式非規範化數據庫的介紹,但是面對實例的時候仍然是一頭霧水.(官網上面的實例只有兩三個collection,感覺比實際應用簡單太多)
每年一個賽季,一個聯賽對應多隻隊伍,每個隊伍有多名隊員.隊員屬性有身高體重所屬球隊球衣號碼場上位置(隊員有可能轉會,但某一特定時間只屬於一個球隊) .聯賽有例行賽,季後賽之分,每場比賽有主/客隊,需要記錄下每個上場隊員的得分/籃板/助攻/蓋帽/搶斷以及每一個事件的時間戳.每場比賽對應多個新聞報道文章
典型應用場景:
最新10場比賽的主/客隊得分,勝負
所有球隊的積分排名
所有球隊在本賽季的平均得分/籃板/助攻/蓋帽/搶斷 前10名排行榜
所有球員在本賽季的平均得分/籃板/助攻/蓋帽/抄截 前10名排行榜
某場比賽中主客隊球隊本場比賽的得分籃板助攻命中率等
某場比賽中主客隊球員在本場比賽的得分籃板助攻命中率等
所有球員在某一賽季中的各項數據排行
某位球員在各賽季中的平均各項數據(轉會過的球員有可能在不同球隊)
可否給出一完整的資料模型結構設計,萬分感謝!
一些想不明白的問題:
是否應該把球員嵌入到球隊中?如何處理轉會問題?
是否應該把每場比賽的數據嵌入到每場比賽中?如果是,又如何關聯球員與每一次得分/..事件的關係?
在哪裡非規範化數據,感覺不管怎麼設計,在匯總球隊,或者球員的歷史數據的時候,和做排名的時候,都要掃描整個數據庫,這不科學吧...
在哪裡做索引可以顯著的提高效能?
這個應用場景到底合適不合適用nosql.................
大的原則是根據 Access Pattern 來設計，幸運的是我們已經有典型應用場景了。
球隊-球員的一對多關係，嵌入或分開都可以，主要是看這兩個數據是不是經常在一起使用。一起用的例子：SegmentFault的問題和答案，也是一對多，但是經常一起顯示。如果不一定，也可以分開，然後在球隊裡加入球員的名字，_id，效力時間等基本信息，這樣的 denormalization 就需要更新的時候多更新一個地方了。但由於這個資訊的更新（例如轉會）頻率很低，讀取非常多，所以還是值得的。
統計。如果重新計算球員的歷史數據，不論用什麼數據庫存，都需要遍歷整個資料庫，對吧？這就又是一個讀寫之前的權衡了。顯然資料更新相較查詢少了很多，快取下統計資料是有意義的。再者，有些統計數據是不變的，例如給定賽季一隊的數據。更新的時候，可以即時更新，也可以快取下一些中間結果，例如平均值來自總數和次數，幫助計算。或者，每場結束後、每天更新一次都是可能的辦法。
每場比賽的數據與比賽有關，也與球員有關，但是它經常跟某一個同樣查詢麼？如果不是，而只為統計服務，放到單獨的 collection 裡也挺好。
索引能幫你更快找到數據，但是不能幫你減少結果數據集。資料模型設計出來，選索引就是很自然的事了。