Думаю, твоя голова заражена мангузами или монгузами?
Ну, я не английский майор, так что я понятия не имею, что такое множественное число.
В любом случае, это подводит нас к теме этой лекции, население Мангуста.
Что такое популяция Мангуста и
как она полезна в нашем экспресс-приложении?
Давай поговорим об этом дальше.
Как мы поняли, базы данных документов, базы данных NoSQL,
не разработаны с учетом отношений.
Все, что вам нужно в документе, хранится полностью внутри документа.
Ну, это в значительной степени то, как вещи работают с базами данных NoSQL, такими как MongoDB.
Таким образом, у вас нет поддержки отношений,
с которыми вы могли бы быть более знакомы из мира реляционных баз данных.
Там, где у вас есть записи, а затем записи могут ссылаться на другие записи и так далее.
И затем вы присоединяетесь, чтобы присоединиться к информации из записей и так далее.
Таким образом, такая поддержка не существует в базах данных NoSQL,
по крайней мере, в значительной степени.
MongoDB предпринял несколько шагов в этом направлении, даже с базами данных NoSQL.
Но в целом базы данных документов предполагают, что все документы являются автономными.
Таким образом, что означает, что вся информация, которая требуется, находится в пределах одного документа.
Теперь, конечно, бывают ситуации, когда у вас есть другие документы, которые
уже содержали информацию.
И вы можете извлечь эту информацию в существующий документ,
а не дублировать эту информацию.
Таким образом, это где MongoDB или Mongoose,
позволяет хранить ссылки на другие документы в текущем документе.
Ссылка на другой документ делается с помощью ObjectID этого
другого документа.
Теперь, если это так, то Mongoose позволяет вам выполнить способ
взятия информации из другого документа, а затем вложение ее в
правильный документ, используя поддержку популяции Mongoose.
Это то, что мы обсудим чуть более подробно.
Сам Mongoose, как мы понимаем, будучи модулем, построенным
поверх MongoDB, не имеет явной поддержки для
соединений, как мы говорим о соединениях в мире SQL.
Чтобы понять, как эта ссылка на другой документ в документе помогает нам и
как она на самом деле структурирована, давайте рассмотрим пример.
В этом примере мы рассмотрим документ блюд, который мы
использовали в нашем упражнении.
В документах посуды, которые мы храним на стороне сервера,
мы заметили, что мы также храним комментарии.
И в комментариях мы также сохраняем поле автора в комментариях.
И поле автора явно содержит имя человека, который
представил этот конкретный комментарий.
Теперь, так как у нас уже есть документ пользователя
в нашей базе данных, как мы видели в этом модуле.
Мы расширили наш экспертный сервер для поддержки пользователей и, таким образом,
вы можете зарегистрировать пользователя и что вы можете аутентифицировать пользователей и так далее.
Таким образом, документ пользователя может содержать дополнительную информацию о пользователе уже.
И поэтому, когда комментарий публикуется пользователем,
вместо того, чтобы хранить имя пользователя в самом комментарии,
почему бы не иметь ссылку на конкретного пользователя, который опубликовал комментарий?
Это полезно не только с точки зрения возможности иметь
дело с тем, что этот комментарий опубликован конкретным пользователем.
Позже мы увидим, что если вам нужно разрешить пользователям изменять или
удалять документы, вы можете ограничить вид
работы конкретного пользователя только теми комментариями,
которые этот конкретный пользователь опубликовал ранее.
Несмотря на то, что мы используем вложенные документы в нашем документе Mongo.
Если мы можем ссылаться на другой документ в поддокументе с помощью ObjectID,
то Mongo помогает нам сделать популяцию этой
информации из другого документа в текущий документ.
Вот где население Мангуста приходит нам на помощь.
Продолжая эту идею, позвольте мне показать вам подробный
пример из схемы комментариев, которую мы определили ранее.
Таким образом, в CommentSchema у нас уже есть поле рейтинга и
поле комментария, которое мы там уже указали.
Раньше у нас было поле автора.
Для поля автора ранее мы сохраняли автора в
виде строки и, Значение по умолчанию также для автора.
Теперь в хранении автора в виде строки типа, если мы теперь превратим
автора в тип Mongoose.Schema.Types.ObjectID.
Это означает, что поле автора теперь будет содержать ObjectID,
который является ссылкой на документ пользователя.
Как убедиться, что это ссылается на документ пользователя?
Таким образом, это дополнительное свойство под названием ref, которое указывает, что
схема документа, который вы ссылаетесь здесь, имеет тип, пользователь,
схема и модель, которые мы уже добавили ранее.
Таким образом, в этом случае схема комментариев теперь расширена для хранения информации об авторе,
но информация об авторе находится в виде ObjectID.
Которая является ссылкой на пользовательский документ, который уже хранится в нашей базе данных.
Итак, как это нам поможет?
Вот где, как я сказал, население Мангуста приходит к нам на помощь.
Так как работает население Мангуста?
С популяцией Mongoose, способ работы популяции Mongoose заключается в том, что
он автоматически заменяет указанные пути в текущем документе.
Который имеет ссылку на другой документ по информации из этого другого документа.
Таким образом, в схеме комментариев, например, у вас есть поле автора, которое
ссылается на ObjectID документа пользователя, который уже находится в вашей базе данных.
Таким образом, с популяцией Mongoose, когда вы просите Mongoose
заполнить этот документ блюдо, то он будет заполнять информацию об авторе в поле комментария
из документа пользователя.
Таким образом, информация о конкретном авторе, на который ссылается там, будет
извлечена и добавлена в ваш документ блюдо.
И составный документ будет построен, а затем отправлен вам обратно.
Как мы можем обеспечить, чтобы это произошло?
Вот где перекрестные ссылки с ObjectID, как мы видели, помогают нам.
Как население на самом деле происходит в коде?
Взгляните на то, как мы будем заполнять,
например, документ блюд, который мы только что видели ранее.
Раньше мы делали блюда. Найти все блюда в нашей базе.
Теперь, как только вы найдете документ Блюда, вы можете сказать заполнить.
А затем поставлять внутри заполненной, в качестве
параметра, конкретное поле, которое необходимо заполнить.
Итак, здесь мы указываем comments.author.
Теперь ожидается, что поле comments.author
на самом деле является OjectID, который ссылается на документ пользователя.
И вот как мы уже настроили нашу схему комментариев.
Таким образом, этот вызов заполнения, который мы выполняем здесь, затем пойдет и
извлечет из базы данных каждую запись автора или запись пользователя.
А затем возьмите этот документ пользователя и
заполняет его в документ посуды, чтобы построить составной документ отсюда.
И после этого, конечно,
есть последующая обработка данных, которые вы получили.
И затем ответ или возврат данных клиенту может произойти в этот момент.
Но, конечно, позвольте мне предупредить вас, что эта операция
с населением — непростая задача для сервера.
Потому что каждое блюдо, вам придется изучить каждый комментарий.
Затем для каждого комментария вам нужно узнать их ObjectID для
пользователя.
Затем вы идете и извлекаете этот документ пользователя, а
затем заполняете его внутри документа блюдо.
И затем, это должно повторяться для
каждого комментария, который содержится в этом документе Блюда.
Это по существу означает, что на стороне сервера потребуется гораздо больше времени
для завершения запроса и отправки информации обратно на клиентскую сторону.
Поэтому я бы предложил, чтобы вы использовали заполнение очень разумно.
Вы должны использовать его только в тех случаях, когда вам действительно нужна эта информация.
Если, например, вы просто создаете меню для своего ресторана.
Когда вы просто создаете меню для своего ресторана,
вам может не понадобиться вообще заполнять информацию об авторе каждого
комментария в документе комментария.
Потому что, когда вы просто рендеринг меню для вашего ресторана,
вы не будете показывать комментарии к этому конкретному блюду.
Но вместо этого, если пользователь изучает конкретное блюдо и
хочет увидеть комментарии в этот момент,
вы можете выполнить запрос на стороне сервера.
А затем получить информацию комментария с другой информацией автора,
заполненной в и получить ее для использования в пределах нашей клиентской стороны.
Так что опять же, заполнение является прекрасным способом делать вещи, когда
это необходимо, но использовать его очень справедливо, только когда вам действительно требуется информация.
Таким образом, гибкость, которая обеспечивает
нам заполнение, является тот факт, что нам не нужно заполнять, когда нам не нужно.
Но мы можем заполнить информацию, когда нам действительно нужна эта информация.
С этим быстрым пониманием популяции Мангуста,
давайте перейдем к упражнению, где мы будем изменять схему Блюда,
схему комментариев в схеме Блюда.
А затем использовать Mongoose заполнить информацию в наших блюдах,
когда мы возвращаем информацию о блюде на стороне сервера.
Кроме того, это также означает, что при добавлении комментария к определенному блюду,
автор информации комментария должен быть захвачен на стороне сервера.
Так получилось, что, как мы разработали наши серверы, у
нас уже есть эта информация, предоставляемая нам.
Когда мы аутентифицируем пользователя, информация пользователя уже загружается в каждый
запрос, который приходит со стороны клиента.
И поэтому они используют эту пользовательскую информацию, доступную нам.
Поэтому, когда мы публикуем комментарий на стороне сервера, мы также
захватим идентификатор пользователя, а затем сохраним его в поле автора схемы комментария.
Это должно быть сделано автоматически на стороне сервера.
Клиенту не следует разрешать явно заполнять поле автора.
Но серверная сторона должна проверять пользователя, и только для
пользователей, которые вошли в систему, вы разрешаете им, в первую очередь, публиковать комментарии.
А затем, когда они
будут публиковать комментарии, вы автоматически заполняете поле автора для этого документа комментария,
заменив поле автора на ObjectID пользователя.
Теперь, в упражнении, вы увидите, как я делаю это.
Так что следите за этой конкретной вещью в упражнении.
С этим мы завершим эту лекцию,
давайте перейдем к упражнению, чтобы изучить использование популяции Мангуста.
[ МУЗЫКА]