Использование mongodb для создания веб-приложений, особенности схемы - PullRequest
1 голос
/ 26 января 2012

Я создаю веб-приложение с компонентом создания и отправки динамического опроса.Я использую MongoDB для хранения схемы формы и отправленных форм.

Я могу представить себе организацию этого несколькими различными способами:

  1. Имея все представления формы иСхемы форм как документы в одной коллекции.

  2. Имеют отдельные коллекции для всех схем форм и всех отправляемых форм

  3. Имеют отдельную коллекцию для всехформировать схемы и создавать новую коллекцию для всех представлений формы для каждой схемы.

Я все еще исследую это, и я из мира RDBMS, я нубв базы данных NoSQL.У кого-нибудь есть какие-либо советы?


РЕДАКТИРОВАТЬ 1 Забыли адрес для встраивания ответов в качестве свойства в документ схемы формы.

Ответы [ 2 ]

2 голосов
/ 26 января 2012

Наличие всех отправленных форм и схем форм как документов в одной коллекции.

Вы хотите избежать этого (# 1). Простая причина здесь в том, что форма представление играет другую роль, чем форма схема . Смешивание их в одной коллекции усложнит запрос.

Иметь отдельные коллекции для всех схем форм и всех отправляемых форм

Чтобы уточнить, звучит так, будто вы предлагаете две коллекции: schema and представление`.

Это логичный способ продолжить. У вас будет одна маленькая коллекция schema и одна большая коллекция submission.

Ключевым ограничением будут ваши запросы к этой коллекции submission. Планируете ли вы делать запросы "по типам"? Или основные запросы сосредоточены на «типе представления»?

Если вы в конечном итоге включите «тип отправки» в каждый запрос, то имеет смысл ...

Создайте отдельную коллекцию для всех схем форм и создайте новую коллекцию для всех отправлений формы для каждой схемы.

Причина этого - просто индексы. Если у вас есть одна коллекция, вам понадобится указатель на «тип». Таким образом, создавая отдельные коллекции, вы можете сохранить индекс. Тем не менее, если вам когда-нибудь понадобятся функции шардинга, это может помочь в управлении многими коллекциями.

Конечно, вы можете обойти этот «дополнительный индекс», проявив творческий подход к _id. MongoDB имеет автоматически сгенерированный ObjectId, который он будет использовать по умолчанию, вроде идентификатора автоинкремента. Однако вы можете переопределить это и создать более умный _id, что-то вроде submissionid_userid.

Честно говоря, я предпочитаю последний вариант. Но на самом деле № 2 и № 3 являются хорошими вариантами, на самом деле это просто вопрос компромиссов с точки зрения сложности кода и сложности управления.

1 голос
/ 26 января 2012

Я бы пошел на две коллекции: форма и представления .

Этот подход хорошо масштабируется по горизонтали, так как у вас есть только две коллекции, о которых нужно беспокоиться.
Я согласен с @Gates VP относительно предоставления пользовательских _id, а не значений по умолчанию objectId, так как вас пощадилиНужен дополнительный индекс.

В коллекции submissions, если вы установите для формата _id значение formID_userID, чтобы получить все представления, все, что вам нужно сделать, это:

db.submissions.find({'_id': '^formID'})

Бонус здесьЯкорное регулярное выражение будет использовать индекс _id_, поэтому он эффективен.


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

http://www.10gen.com/presentations/mongodb-tokyo-2012/basic-application-and-schema-design http://www.10gen.com/presentations/mongosv-2011/schema-design-principles-and-practice

...