У меня есть схема db, которая выглядит как традиционная Post, Comments schema s.t. У сообщений много комментариев.Mongo Collection in a Collection
Бывают случаи, когда мне нужно найти много комментариев для определенного поля и вообще не хотеть сообщений. Так что что-то вроде db.posts.find({$where this.comments.field == blah})
, которое возвращает сообщения, а не комментарии, не очень хорошо.
То, что я сейчас делаю, тоже нехорошо. У меня есть поле, называемое комментариями в коллекции Posts, которое хранит _ids комментариев в сообщениях. Это относится к ним слишком сильно, как к реляционной базе данных.
Вместо этого я хотел бы сохранить коллекцию для каждого из сообщений и комментариев. Затем вместо того, чтобы вставлять данные «Комментарии» в «Сообщения» и пытаться синхронизировать эти данные с данными коллекции «Комментарии», я хотел бы встроить сам комментарий в сообщение. Я думаю об этом, как о наличии подкатегории. Это стандарт? Каковы минусы этого? Большинство обсуждений, которые я вижу по этому поводу, предназначены для внедрения документов, а не для встраивания коллекций.
Когда вы говорите поддокумент, вы имеете в виду субколлекцию? Почему у меня нет подкатегории под названием «Комментарии», а затем, когда мне нужно ссылаться на «Комментарии без сообщений», я просто прошу «Комментарии»? – user592419
Подкомплект/подмножество 'comments' - это что-то вроде' {_id, title, comments [{id, текст}, {_id, text} ...]} ' –
Я считаю, что использование встроенных массивов' _id' очень раздражает - _id' ** не ** зарезервированное имя во встроенных массивах - это не стандартный (уникальный) ключ, а не первичный ключ, и его можно изменить. Кроме того, в массивах нет семантики коллекции, их нужно работать совсем по-другому, поэтому, пожалуйста, не вносите вклад в множество раздражающей дезинформации, которая уже существует.Нет «подколлекций» – mnemosyn