談MongoDB的應用場景

 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操作即可完成。對于客戶具體的附件清單資訊可以做相似的設計，即點選連結後再進入到具體的客戶附件文檔檢視界面。