使用MongoDB收藏與索引

我是MongoDB的新手，並且試圖讓我的數據建模範例處於領先地位。使用MongoDB收藏與索引

我認爲如果我提供一點背景是最好的。假設我是一家向顧客出售東西的公司，但是我的商品價格並不固定：每一次購買都有一個迭代交易順序。（即我公司的報價，他們的還價，我公司的反櫃檯報價等）。我的數據庫的目的是存儲交易的演變。我的公司有能力用不同的選項進行還價。獨特的客戶的數量< 1000因此，我有以下設置：

{ 
    customer_id : Number 
    unique_deal_id: Number 
    parent_unique_deal_id: Number 
    child_unique_deal_id's: [Number] 
    deal : { 
    // info on price of each good negotiated 
    } 
}

如果我％的查詢100涉及）檢索特定交易或b）檢索交易的「分支」，在MongoDB就是我試圖將客戶標準化和分離到他們自己的集合中的地方，還是將所有東西放在單個集合（和索引客戶）中的想法？

來源

2013-07-22 gone

我不認爲文檔結構真的是這裏的問題。讓我們從另一個角度來看待這個問題。想想這就像會計分類賬。

line #, Date, Description, Count, Price each 
1, 02/25/2013, Super widgets, 1000, $1 // <-- Strike though font 
2, 02/25/2013, Super Widgets, 5000, $0.50 // <-- Strike though font 
3, 02/26/2013, Super widgets 3500, $0.75

最後一行＃3是當前的計數。通過查看日期，你可以看到保存的內容和不保存的內容。「交易」的演變非常類似於您的帳戶聲明，只需將交易記錄項目更改添加到交易中，並「扣除」未保留的交易記錄（不要刪除它們，只需標記它們不活動）。

我覺得你有3個類別：

經銷商 - 公司
交易（經銷商之間和你）
交易歸檔（舊貨）

{ _id：mongoid ， company_id：整數， ...其他字段... transaction_log：[ {active： boolean，id：integer，date：datetime，description：text，count：integer，price：float？/ integer？ }， {active：boolean，id：integer，date：datetime，description：text，count：integer，price：float？/ integer？ }， {active：boolean，id：integer，date：datetime，description：text，count：integer，price：float？/ integer？ }， {active：boolean，id：integer，date：datetime，description：text，count：integer，price：float？/ integer？ }， ... ] }

來源

2013-07-22 01:15:43 Daniel

對不起，花了一段時間找回你 - 不得不搶吃晚飯。有趣的想法，但。我只是想想這是如何轉化爲Mongo的。通過添加事務，這是否與向陣列添加文檔相對應，每個陣列都跟蹤「操作」 – gone

我將根據需要更新消息，格式化！ – Daniel

我認爲這是一個設計討論，這可能是最好的現場做了，但我希望，我可以引導你在正確的方向。

聽起來好像有3個主要實體涉及此方案：客戶，交易和交易出價歷史記錄。嵌入數據或將數據存儲在單獨集合中的決定是特定於開發人員應用程序的設計決策。如果您沒有學習一些基礎知識，我強烈建議您參加免費的在線培訓課程。有一個關於基本模式設計的課程可以幫助你在思考過程中引導你。在您考慮您的主要數據訪問模式時，您似乎已經直覺地知道如何做出決定。

根據我對您的數據的理解，我可能會將您的客戶數據存儲在它自己的集合中。原因是您的應用可能會獨立於交易訪問客戶詳細信息，而且似乎沒有必要以原子方式訪問客戶和交易（Mongodb旨在提供文檔級別的原子操作）。這些都是爲什麼重複所有數據中的客戶數據可能不是更好的選擇。一旦客戶登錄，您可以提取客戶數據，並且擁有上下文（即客戶ID）。然後您可以使用此上下文來讀取和更新交易信息。你的交易集合看起來不錯。通過客戶ID，您可以抽出一筆交易，以及各種交易分支（如果您想引用它們，可以參考www.mongodb.org上的樹形設計模式 - 請注意您的設計模式與標準匹配相當密切）。儘管將交易歷史嵌入交易存在一個危險。請注意，單個文檔目前有16MB的限制。如果您保持交易歷史子文檔精簡，您應該能夠存儲大量歷史記錄;但是，如果您的應用程序像微招標應用程序那麼16MB限制可能會造成問題;如果是這種情況，那麼您需要將交易歷史記錄存儲到另一個集合中的單個文檔中。如果它是有意義的，你可以選擇在你的交易中存儲一些冗餘數據，如最近的10個出價，如果它使你的應用程序更容易讀取（與更新多個目標的可能性相比）。在任何情況下，如果它是合理的，嵌入它將爲您的應用程序提供簡單和更快的數據訪問。另外，如果您最終將交易歷史記錄嵌入到交易中，那麼您的文檔將隨着每個文檔的大小不斷增長。 MongoDB在磁盤上連續存儲文檔以便進行快速更新。其含義是，如果文檔超出了當前分配的空間，MongoDB會將整個文檔移動到磁盤上的另一個位置。這可能會降低更新速度，如果您的應用程序在更新上很重要，可能會擔心。爲了防止不合時宜的文檔移動，請在mongodb.org網站上查找使用填充因子選項和「powersof2」設置。

來源

2013-07-22 01:56:14

非常豐富。我不知道文檔大小有16MB的限制 - 這對我來說可能是一個問題。萬分感謝！ – gone

此外，感謝「powersof2」設置參考 - 看起來像它會很有用 – gone

使用MongoDB收藏與索引

回答

相關問題