Этот вопрос действительно довольно расплывчатый. Некоторые вещи, которые могут относиться или не относиться к вам (в произвольном порядке):
Сократить подробные имена полей
Это лучше всего иллюстрируется на примере:
{
surname: "Smith",
forename: "John",
location: { grid_e: 100.02, grid_n: 450.08 }
}
Предыдущий документ можно сократить, удалив ненужные слова в именах различных полей.
{
sn: "Smith",
fn: "John",
loc: { e: 100.02, n: 450.08 }
}
Это даст вам очень небольшую экономию места, но она будет умножена на размер каждого документа (количество полей) и количество документов (может стать значительным, если у вас есть миллионы). Вот превосходное сообщение , в котором обсуждаются преимущества и недостатки этого метода.
Закрытые коллекции
Ограниченные коллекции позволяют указать ограничение на количество документов, которые вы хотите сохранить. Он работает по принципу «первым пришел - первым вышел» (самые старые документы будут удалены). Это особенно применимо, если вы регистрируетесь и хотите хранить самые последние x документы, но старые не имеют значения.
Существуют некоторые предостережения относительно использования ограниченных коллекций. См. MongoDB документы для получения полной информации.
Рассмотрим отношения ваших документов
Документы могут иметь встроенные документы или связи с другими документами (в других коллекциях) в стиле внешнего ключа. Плюсы и минусы каждого подхода обсуждаются часто , но в конечном итоге вам решать, какой подход вам подходит.
На примере блога может быть, что у каждого поста есть автор. Вы можете либо встраивать эту информацию об авторе в каждое сообщение, либо можете поместить их в собственную коллекцию authors или users. Последний подход позволит сэкономить место, особенно если многие пользователи часто делают много сообщений (а не только один или два). Имейте в виду, что вам придется выполнить дополнительный вызов базы данных, так как нет соединений.
Редактировать: Расширение отношений
Отношения между документами могут быть выполнены несколькими способами в дополнение к их встраиванию. Вы можете просто использовать идентификатор соответствующего документа следующим образом (повторно используя приведенный выше пример блога):
{
_id: <whatever>,
title: "Document Relationships in MongoDB",
body: "bla bla bla bla",
// ...
user_id: <id of the user document>
}
А в коллекции users этот связанный документ будет существовать:
{
_id: <whatever>,
name: "Mark Embling",
email: "example@markembling.info",
///...
}
Это, вероятно, самый простой из возможных подходов к отношениям (помимо их встраивания), но вы должны будете поддерживать их в своем собственном коде полностью . Вам нужно будет позвонить, чтобы захватить соответствующего пользователя, когда вам это нужно, и обновить его, когда это может понадобиться. Тем не менее, я не вижу ничего плохого в этом подходе, и я видел его несколько раз.
Аналогичный подход заключается в использовании DBRef. Это более формальный метод описания отношений, подобных приведенным выше. Вместо того, чтобы просто вводить идентификатор другого документа, вы указываете DBRef, который является своего рода формализованной ссылкой на другой документ. Я надеюсь, что в этом есть смысл. Оба описанных мною подхода подробно обсуждаются в документации mongodb. Стоит отметить, что ручные ссылки будут занимать (немного) меньше места, чем DBRef, поскольку DBRef содержит дополнительную (возможно, избыточную) информацию, например, на какую коллекцию ссылаются. Он имеет преимущество в том, что изначально поддерживается многими библиотеками, поэтому он немного облегчает вашу жизнь.
В конечном счете, какие методы работают и актуальны, зависит от того, что вы пытаетесь сделать. Рассмотрите варианты, компромисс и сделайте колл в отношении того, стоит ли что-то делать. И эксперимент.