MongoDB和Mongoose：文檔參考ID的嵌套數組

Question

我一直在研究MongoDB，並遇到了一種特別有趣的模式，用於存儲文檔之間的關系。 此模式涉及父文檔，其中包含引用子文檔的ID數組，如下所示：

//Parent Schema
export interface Post extends mongoose.Document {
  content: string;
  dateCreated: string;
  comments: Comment[];
}

let postSchema = new mongoose.Schema({
  content: {
    type: String,
    required: true
  },
  dateCreated: {
    type: String,
    required: true
  },
  comments: [{ type: mongoose.Schema.Types.ObjectId, ref: 'Comment' }] //nested array of child reference ids
});

和被引用的孩子：

//Child Schema
export interface Comment extends mongoose.Document {
  content: string;
  dateCreated: string;
}

let commentSchema = new mongoose.Schema({
  content: {
    type: String,
    required: true
  },
  dateCreated: {
    type: String,
    required: true
  }
});

在我從前端發送請求以創建新評論之前，這一切似乎都很好。 該請求必須包含Post _id（以更新帖子）和新的Comment，這兩者都是使用常規關系數據庫時將發送的請求所共有的。 當需要將新的注釋寫入數據庫時​​，將出現問題。 而不是像在普通的關系數據庫中那樣進行一次數據庫寫入，我必須進行2次寫入和1次讀取。 第一次寫入以插入新的Comment並檢索_id。 然后，通過與請求一起發送的Post _id進行讀取以檢索Post，這樣我就可以將新的Comment _id推送到嵌套的引用數組。 最后，最后寫入以將Post更新回數據庫。

這似乎效率極低。 我的問題有兩個：

1. 有沒有更好/更有效的方法來處理這種關系模式（父級包含子級參考ID的數組）？

2. 如果不是這樣，與使用A）將父_id存儲在類似於傳統外鍵的子級屬性中或使用B）利用MongoDB文檔並將Comments數組存儲為A相比，使用此模式有什么好處？與注釋的參考ID數組相對。

預先感謝您的見解！

Answer 1

關於第一個問題：

您特別要求一種更好的方式來處理存儲在父代中的子代ID。 我很確定，如果必須使用這種模式，那么沒有更好的方法來解決這個問題。

但是關系數據庫中也存在此問題。 如果要將帖子保存在關系數據庫中（使用該模式），則還必須首先創建評論，獲取其ID，然后更新帖子。 當然，您可以在單個請求中發送所有這些任務，這可能比使用貓鼬更有效，但是需要完成的工作類型是相同的。

關於第二個問題：

相對於變體A的好處是，例如，您可以獲取該帖子，並立即知道它有多少評論，而無需讓mongodb遍歷可能是數百個文檔。

相對於變體B的好處是，由於mongos的文檔大小限制為16MB，因此您可以在單個文檔（單個帖子）中存儲更多的注釋引用 ，而不是整個注釋。

---

但是，您所提到的缺點是，維持這種結構效率很低。 我認為，這只是一個展示場景的示例，因此我將做以下事情：我將根據具體情況決定使用什么。

• 如果該文件將被讀了很多，並沒有太大的寫入，這是不太可能長得比16MB大：嵌入子文檔。 這樣，您可以在單個查詢中獲取所有數據。

• 如果您需要引用多個其他文檔中的文檔，並且您的數據確實必須一致，那么您只能選擇引用它。

• 如果需要從多個其他文檔中引用文檔， 但是數據一致性不是那么重要，並且第一個項目符號的限制適用，那么請嵌入子文檔，並編寫代碼以保持數據一致。

• 如果您需要從多個其他文檔中引用該文檔，並且它們被寫得很多，但不經常閱讀，則最好引用它們，因為這樣更易於編碼，因為您無需編寫同步重復數據的代碼。

在這種特定情況下（發布/評論），從孩子那里引用父母（讓孩子知道父母_id ）可能是一個好主意，因為它比其他方法更容易維護，並且如果文檔大於16MB，它們是直接嵌入的。 如果我可以確定的話，文檔不會超過16MB，將它們嵌入會更好，因為這樣可以更快地查詢數據