將文檔的id保存爲另一個文檔ObjectId或String

讓我們看看一個簡單的「壞」例子：假設我有兩個集合'person'和'address'。並且讓我們在'地址'中假設我想存儲地址關聯的人的'_id'。將「引用鍵」項存儲爲「地址」集合中的ObjectId vs字符串是否有任何好處？將文檔的id保存爲另一個文檔ObjectId或String

我覺得像把它們存儲爲字符串不應該傷害，但我沒有在mongo工作很長時間，也不知道如果我遵循這種模式會不會傷害到道路。使用人Store _Id as object or string in MongoDB? 而其說的ObjectId是快了，我認爲它的真實，如果你正在讀取/父集合中使用的ObjectId（用於例如更新讀取/更新「人」的收集：

我在這裏閱讀文章。 ._id作爲ObjectId），但我找不到任何暗示如果通過其他集合中的字符串id表示進行搜索（在我們的示例中，通過person._id作爲字符串搜索地址集合中的內容），結果可能爲true

您的反饋非常感謝。

來源

2016-03-17 Deewendra Shrestha

如何，這是一個不同的問題？ ObjectId以12字節存儲。 ObjectId的十六進制字符的字符串是24個字節（僅適用於字符，正尾隨後加大小參考）。更多的空間，更多的時間。比較慢！這應該不難解決。 –

你是對的，正試圖用燼數據處理事情，並沒有看到轉換objectid到字符串，並返回到objectId很多點，我尋找方便而不是性能。今天早上我做了一個搜索，這個問題也被問到了其他的形式。 –

爲了記錄您在這裏接受的答案，提出了另一個重要的觀點。無法手動將其重新轉換爲字符串或ObjectId值，您無法在不同的「類型」上將事物匹配在一起。我個人更喜歡所有的外部API使用擴展的JSON格式'{「_id」：{「$ oid」：「56ea9e8bb1e015d13b376db5」}}'因爲如果我的客戶端實際上可以反序列化回'ObjectId'，那麼我讓它知道數據實際上是什麼。 –

無論性能如何，您應該以與您所指的_id字段相同的格式存儲「參照鍵」。這意味着，如果你的文檔被稱爲是：

{ _id: ObjectID("68746287..."), value: 'foo' }

然後你把它稱爲：

{ _id: ObjectID(…parent document id…), subDoc: ObjectID("68746287...")

如果你指向文檔有一個字符串形式的ID，然後將其倒是像：

{ _id: "derick-address-1", value: 'foo' }

然後你把它稱爲：

{ _id: ObjectID(…parent document id…), subDoc: "derick-address-1" }

除此之外，因爲你在談論者和地址，它可能會更有意義不有他們在一共兩個文件，而是嵌入文檔：

{ _id: ObjectID(…parent document id…), 
    'name' : 'Derick', 
    'addresses' : [ 
    { 'type' : 'Home', 'street' : 'Victoria Road' }, 
    { 'type' : 'Work', 'street' : 'King William Street' }, 
    ] 
}

來源

2016-03-17 09:36:36 Derick

至於使用string作爲文檔ID，在meteor collection，您可以生成文檔ID或者Random.id()字符串或Meteor.Collection.ObjectID()爲ObjectId。

在這次討論中循環，Mongodb string id vs ObjectId，這裏是一個很好的總結，

的ObjectId優點

- it has an embedded timestamp in it. 
- it's the default Mongo _id type; ubiquitous 
- interoperability with other apps and drivers

的ObjectId缺點

- it's an object, and a little more difficult to manipulate in practice. 
- there will be times when you forget to wrap your string in new ObjectId() 
- it requires server side object creation to maintain _id uniqueness 
- which makes generating them client-side by minimongo problematic

字符串優點

- developers can create domain specific _id topologies

字符串缺點

- developer has to ensure uniqueness of _ids 
- findAndModify() and getNextSequence() queries may be invalidated

所有這些信息上面是基於meteor框架。對於Mongodb，最好使用ObjectId，原因在於你的問題中存在問題。

來源

2016-03-17 06:07:45 zangw

將它存儲爲objectId是人爲的。由於ObjectId的大小是12個字節，而字符串需要24個字節，所以速度更快。

此外，您應該嘗試去規範化您的集合，以便您不需要創建2個集合（與RDBMS相反）。

喜歡的東西，這可能是一般更好：

{ _id : "1", 
    person : { 
      Name : "abc", 
      age: 20 
      }, 
    address : { 
      street : "1st main", 
      city: "Bangalore", 
      country: "India" 
      } 
}

但同樣，這取決於你的使用情況。有時這可能不適合。

希望有幫助！ :)

來源

2016-03-17 06:08:43 Kaushal

將文檔的id保存爲另一個文檔ObjectId或String

回答

相關問題