MongoDB「關係型」應用程序的體系結構

Question

這是該項目，粗略地說：我們有用戶，我們有民意調查，用戶既可以創建民意調查，也可以投票現有民意調查。當然，一個用戶每次投票只能投一次。

對我來說這顯然是關係型的，所以原則上NoSQL是沒有意義的。但後來我讀了一點，得出的結論是，你確實可以在MongoDB中建立關係，所以我來到這個計劃中，我想知道在繼續之前它是否是Mongo-OK。

在我們店所有的用戶數據，包括ID的表/集合稱爲用戶（我猜蒙戈文件的默認_id會好嗎？）

在另一臺/收集所謂民意調查，我們將有一個id ，問題，可能的答案和（這裏是我開始懷疑的地方）一個包含所有已經投票的用戶ID的數組？另外還有作者的用戶ID和用戶名（我知道這是重複的，但是我在某處讀到我在mongo中這樣做是有道理的，所以你不必爲了知道用戶的用戶名而啓動另一個查詢）。

在MySQL中，我會創建一個帶有投票關係的表（用戶ID已經投票pollID），但我猜想在Mongo中，將這些數據包含在投票文件本身中是否有意義？當然，這個用戶ID數組將會不斷更新，是嗎？

如果我想列出由給定的用戶ID創建的所有民意調查？我知道你可以使用find（），但至少在這種情況下它和MySQL一樣高效？此外，每個民意調查將在一個類別，你也必須能夠按類別進行排序等，但我不想進一步複雜化。

Answer 1

在我看來，一個有效的方法去做這件事將是有一個Users集合，其中存儲所有與用戶有關的數據，然後有一個Polls集合，正如你所提到的，它存儲一組數組ObjectId引用回您的用戶。

此數組還可以包含一些其他信息，例如任何給定用戶何時應答以及提供的答案的時間戳。

儘管如此，請注意將對象嵌入到數組中並不總是一種好的做法，特別是當它是無界的時候（即：用戶數量將隨着時間增加而增加，從而使得投票對象也會隨時間增加）。儘管如此，我認爲在你的情況下，這對你的應用程序用例場景來說是一個很好的方法，特別是因爲用戶只能對任何給定的輪詢只回答一次，因此限制了對象數組的擴展速度。

此外，關於您對UserId查詢投票集合的擔心，我認爲只要您正確索引您的集合，就不會有任何問題發出find查詢。如果您只想檢索某個用戶創建的民意調查總數而不檢索有關這些民意調查的數據，則可能會在用戶定義一個counter字段，每次用戶創建民意調查時都會增加該字段。