【轉載】談MongoDB的應用情境

標籤：思維   狀態   關係型資料庫   模式   grid   建立   資料   欄位   可行性   

引用：http://blog.csdn.net/adparking/article/details/38727911

MongoDB的應用情境在網上搜尋了下，很少介紹關於傳統的資訊化應用中如何使用MongoDB資料庫方面的內容，比較多的還是介紹日誌的採集和儲存，小檔案的分布式儲存，類似互連網微博應用的資料存放區等方面的內容。在這裡思考下傳統公司資訊化系統中的應用可行性。

首先對於NoSQL資料庫，在資料庫建模上需要重點考慮，徹底放棄傳統的關係型資料庫建模方法，如果將傳統的關係型資料庫表原封不動的映射到NoSQL資料庫，很多NoSQL資料庫本身的優點特性反而無用武之地。其中最重要的就是轉化為面對對象的思維模式，更加關注領域對象和實體資訊。MongoDB資料庫的集合本身就是一個可以包羅永珍的層次化的文檔對象，集合本身還可以包含子集合，形成一個完整意義上的對象。

如果拿一個最簡單的企業客戶資訊管理功能來說，可以看到首先要維護有哪些企業客戶，企業客戶的常用列表，每個人的連絡方式，企業相關的資料文檔，企業的地址資訊，企業的賬戶資訊，爭取企業的拜訪記錄等，這裡講的就是一個最簡單的企業客戶域的對象資訊。

按道理來說公司資訊就是一個完整的對象，企業附屬對象都從屬於企業這個對象，企業這個資訊沒有了其餘附屬對象資訊的生命週期也就結束。如果按這個意義上來說只需要簡曆一個collection集合就可以管理所有事情。但是我看到企業客戶包括了兩方面資訊，一個是偏靜態資訊，如企業基本資料，連絡人，聯絡地址資訊；一個是偏動態資訊，即企業的拜訪記錄等。考慮了企業拜訪記錄本身變動頻繁是動態資訊，可以將企業拜訪記錄拆分出來單獨做為一個文檔對象來管理。如果這樣的話，要完善以上功能只需要建兩個文檔對象，一個是企業客戶基本資料，一個是拜訪記錄資訊。另外還有一個檔案儲存體功能，直接使用MongoDB的GridFS來完成即可。

在企業客戶資訊中，企業客戶即一個集合，在該集合中連絡人資訊為子集合，連絡人的連絡方式（多種連絡方式）資訊可以有兩點考慮，一個是子子集合，也可以直接將多種連絡方式歸併到連絡人對象一層，由於MongoDB的屬性欄位本身就可以方便的擴充，這樣設計可以減少整個集合的層次。（在這裡我的考慮就是，對於1對多關係，對於子表本身就只有一個欄位的都可以考慮合并到父物件裡面減少層次）。這些資訊往往在客戶基本資料錄入的時候就需要完整錄入，一個完整的JSON對象格式可以很方便的作為一個整體存入到MongoDB資料庫中。

對於客戶的拜訪記錄由於動態經常增加，可以單獨設定一個對象，在該對象中增加客戶ID，客戶名稱資訊冗餘，減少後續查詢功能中不必要的對象關聯。對於這個對象我們可以看到會經常增加資料，但是實際增加的資料本身變動卻很少。在拜訪記錄中如果還有和本次拜訪相關的圖片或文檔儲存，也可以很方面的解決問題。

對於客戶文檔資料儲存，前面已經說過了直接使用GridFS來完成即可。GridFS是MongoDB的一個內建功能，它提供一組檔案操作的API以利用MongoDB隱藏檔。對於剛才的情境可以看到，對於增加一個客戶資料的儲存首先調用檔案儲存體API完成非結構化檔案的儲存，儲存完成後可以返迴文件控制代碼ID，這個控制代碼ID可以做為一個子集合直接儲存在客戶主Collection對象上，也可以單獨建立一個客戶ID和檔案控制代碼ID的關聯表，但是個人認為直接建立在客戶主集合對象似乎更好。

基於以上基本思路來分析實際客戶資訊管理需要的具體功能點。

客戶資訊新增功能，在新增介面上需要維護客戶基本資料，客戶的連絡人，地址資訊，客戶的文檔資料資訊，如果不考慮非結構文檔附件，整個頁面本身就是一個完整的JSON對象，可以只調用一次即完成整個層次化集合對象的儲存，而且相當簡單。考慮到附件資訊，即操作分為兩個步驟，首先上傳儲存附件擷取附件控制代碼ID，然後再儲存結構化客戶基本對象資訊。對於客戶拜訪記錄資訊，錄入客戶拜訪記錄首先肯定是要選擇到具體的客戶，選擇到具體客戶後，客戶的ID資訊，客戶的名稱資訊即已經可以擷取到。新增加一條拜訪記錄也是相當簡單的操作即可以完成。

再來看查詢功能，首先看客戶資訊查詢可能是一個模糊查詢功能，而MongoDB對模糊查詢效能是比較弱的，因此儘可能的減少不必要模糊查詢欄位，對於必須的查詢欄位可以在MongoDB對象中增加相應的索引資訊。最重要的就是基於MongoDB資料庫對Join操作的支援很弱，應該在資料模型設計和查詢設計上儘可能的減少不必要的對象關聯操作。當查詢到某一個具體的客戶資訊後，需要查看該客戶具體的拜訪記錄就相當簡單的，只是對拜訪記錄表最簡單的根據客戶ID的一個類where操作即可完成。對於客戶具體的附件列表資訊可以做相似的設計，即點選連結後再進入到具體的客戶附件文檔查看介面。

對於更新功能，基本對象的更新也相當簡單，剩下的就是對於連絡人資訊的更新，連絡人資訊是一個子集合對象，在這裡暫時還沒有看到是需要對這個子集合對象全部更新掉，還是可以做到只更新操作子集合對象中的一條記錄。對於更新操作，仍然需要定位到具體的ID值再進行更新。對於批次更新現在MongoDB本身也提供了相應的操作，類似批次更新客戶狀態操作還是很容易實現的。

以上只是一個最簡單的分析，基於這種分析，以後對於類似主要資料管理系統的應用完全可以遷移到MongoDB資料庫來支撐。另外對於記錄更新不頻繁，對象直接相互關聯和影響小的情境也適合遷移到MongoDB資料庫。在NoSQL資料庫的使用過程中應該盡量避開類似強一致性要求，表間關係複雜，長周期事務等情境。

【轉載】談MongoDB的應用情境