2014-02-14 2 views
0

У меня есть схема db, которая выглядит как традиционная Post, Comments schema s.t. У сообщений много комментариев.Mongo Collection in a Collection

Бывают случаи, когда мне нужно найти много комментариев для определенного поля и вообще не хотеть сообщений. Так что что-то вроде db.posts.find({$where this.comments.field == blah}), которое возвращает сообщения, а не комментарии, не очень хорошо.

То, что я сейчас делаю, тоже нехорошо. У меня есть поле, называемое комментариями в коллекции Posts, которое хранит _ids комментариев в сообщениях. Это относится к ним слишком сильно, как к реляционной базе данных.

Вместо этого я хотел бы сохранить коллекцию для каждого из сообщений и комментариев. Затем вместо того, чтобы вставлять данные «Комментарии» в «Сообщения» и пытаться синхронизировать эти данные с данными коллекции «Комментарии», я хотел бы встроить сам комментарий в сообщение. Я думаю об этом, как о наличии подкатегории. Это стандарт? Каковы минусы этого? Большинство обсуждений, которые я вижу по этому поводу, предназначены для внедрения документов, а не для встраивания коллекций.

ответ

0

Наличие поддокументов в документе является приятным, если вам не нужно рассматривать поддокументы без родительского документа.

В вашем случае, если вы ничего не сделаете с комментариями, лучше вставлять комментарии в каждое сообщение. В случае, если вы хотите найти последние комментарии или комментарии конкретного пользователя, лучше иметь две коллекции. Даже если это кажется реляционным для вас.

+0

Когда вы говорите поддокумент, вы имеете в виду субколлекцию? Почему у меня нет подкатегории под названием «Комментарии», а затем, когда мне нужно ссылаться на «Комментарии без сообщений», я просто прошу «Комментарии»? – user592419

+0

Подкомплект/подмножество 'comments' - это что-то вроде' {_id, title, comments [{id, текст}, {_id, text} ...]} ' –

+0

Я считаю, что использование встроенных массивов' _id' очень раздражает - _id' ** не ** зарезервированное имя во встроенных массивах - это не стандартный (уникальный) ключ, а не первичный ключ, и его можно изменить. Кроме того, в массивах нет семантики коллекции, их нужно работать совсем по-другому, поэтому, пожалуйста, не вносите вклад в множество раздражающей дезинформации, которая уже существует.Нет «подколлекций» – mnemosyn

1

Вместо этого я хотел бы сохранить коллекцию для каждого из сообщений и комментариев.

Это имеет смысл

Я хотел бы, чтобы встроить сам комментарий в сообщении.

Это противоречит тому, что ты сказал

как с суб-коллекции. Это стандарт? [...] Большинство обсуждений, которые я вижу [...], предназначены для встраивания документов, а не для встраивания коллекций.

Это потому, что «встраивание коллекции» не существует, и я не уверен, что это действительно имеет никакого смысла (звучит как материализованное представление мне)

Из того, что Вы сказали в своем вопросе, Я думаю, что две отдельные коллекции имеют наибольший смысл (как это обычно делают для прототипического примера сообщений и комментариев) - это обсуждалось на большой длине (an in short). Затем, чтобы связать их, используйте хороший реляционный способ:

Post { _id : ObjectId("..."), ... } 
Comment { _id : ObjectId("..."), postId : ObjectId("..."), ... } 
+0

Итак, это отвечает на мой вопрос о том, что люди имеют в виду, когда говорят субдокументы, а не подколлекции ... Почему не существуют субколлекции? Почему мы не можем это сделать? Тогда вы получаете лучшее из обоих миров, когда вам действительно нужны только комментарии без сообщений. – user592419

+0

Ну, в чем разница между «подколлекцией» и «db.comments.find()» и «db.comments.find ({« postId »: somePostId})'? Не те ли функции, которые «встроенная коллекция» имела бы? – mnemosyn

+0

A. Большую часть времени мне нужно обоим, поэтому, если бы он был в одном дБ, то было бы хорошо. B. Я использую Meteor, поэтому это также уменьшит количество необходимых подписчиков. – user592419