MongoDB模式嵌入和嵌套唯一鍵

我有一個關係SQL數據庫被改爲MongoDB。在SQL中有三個相關的表格：Farm，Division，Wombat（名稱和目的已針對此問題進行了更改）。還有一個Farmer表，它等同於一個用戶表。MongoDB模式嵌入和嵌套唯一鍵

使用貓鼬，我想出了這個新的模式：

var mongoose = require('mongoose'); 
var farmSchema = new mongoose.Schema({ 
    // reference to the farmer collection's _id key 
    farmerId: mongoose.Schema.ObjectId, 
    name: String, // name of farm 
    division: [{ 
     divisionId: mongoose.Schema.ObjectId, 
     name: String, 
     wombats: [{ 
      wombatId: mongoose.Schema.ObjectId, 
      name: String, 
      weight: Number 
     }] 
    }] 
});

每一個（現在的）嵌套藏品中有一個獨特的領域。這將允許我使用Ajax發送uniqueId和權重（例如）來調整該值，而不是僅在權重改變時更新整個文檔。

這感覺就像是一個不適合MongoDB的SQL適配。有一個更好的方法嗎？

來源

2013-10-16 Guy

一般來說，我相信人們在使用MongoDB時往往會嵌入太多的東西。

最重要的論據是，讓不同的作者對同一個對象使事情變得更加複雜。處理數組和嵌入對象可能會非常棘手，並且一些修改是不可能的，例如因爲沒有positional operator matching in nested arrays。

對於您的特定場景，請注意獨特的陣列鍵might not behave as expected，該行爲可能change in future releases。

這往往需要選擇一個簡單的類似SQL的模式，如

Farm { 
    _id : ObjectId("...") 
} 

Division { 
    _id : ObjectId("..."), 
    FarmId : ObjectId("..."), 
    ... 
} 

Wombat { 
    _id : ObjectId("..."), 
    DivisionId : ObjectId("..."), 
    ... 
}

無論嵌入是正確的做法與否，在很大程度上取決於使用模式，數據大小，併發寫入，等等 - 一個與SQL的主要區別是there is no one right way to model 1:n or n:n relationships，所以你必須仔細權衡每種情況的優缺點。根據我的經驗，擁有一個獨特的ID是一個非常強有力的指標，該文件應該是「一流公民」，並擁有自己的收藏。

來源

2013-10-16 16:31:52 mnemosyn

和另一個downvote沒有解釋。謹慎闡述？ – mnemosyn

MongoDB模式嵌入和嵌套唯一鍵

回答

相關問題