Подходит ли MongoDB здесь? Моделирование регистрации событий с произвольными дополнительными данными - PullRequest
1 голос
/ 13 января 2012

Я пишу базовое веб-приложение для регистрации событий, и мне интересно, будет ли MongoDB хорошим выбором для хранилища данных, и если да, то как смоделировать мой домен.Приложение будет очень маленьким, поэтому производительность и масштабируемость не являются проблемой, однако, когда я начал придумывать модель в терминах СУБД в третьем нормальном смысле, это звучало довольно сложно с точки зрения того, что это такое, и из кусочков, которые я собираю.о Монго, звучало как типичный вариант использования.

Приложение

Приложение позволяет создавать событий , а для участников зарегистрироваться на нихсобытия, указав их имя, дату рождения и т. д. Легко, две таблицы с n: n присоединиться.Сложность заключается в том, что организаторы хотят иметь возможность запрашивать у участников определенных мероприятий информацию, относящуюся к этому событию, например, по одному мероприятию может возникнуть вопрос об их предпочтении в размещении.Я сузил его до двух типов вопросов: те, которые требуют выбора из определенных опций (будет список выбора HTML) и вопросы, которые разрешают ответы в свободном тексте.Кстати, это приложение на Rails в случае, если это имеет значение.

Традиционная СУБД

В СУБД мне, возможно, понадобится таблица для Ограниченный вопрос (где ответы из списка), таблица для Параметры ответа , таблица для Вопрос с произвольным текстом и Ответы с произвольным текстом ;и соответствующим образом связать все это с событием и участником через Регистрация .Если подумать, ссылки между таблицами довольно сложны!

Mongo

Было бы проще моделировать в Mongo?Я подумал, что, возможно, кроме коллекций Attendee и Event , может существовать коллекция Question , в которую встроены разрешенные ответы, если ответов нет, то она бесплатнатекст. Регистрация коллекция, которая связывает Участника с Событием и ссылается на идентификатор соответствующего Вопроса, и встраивает текст ответа?Если текст варианта ответа когда-либо изменится, он может оказаться сложным ... но я думаю, что это компромисс с Mongo.

Это хороший вариант использования для Mongo, если я буду придерживаться Postgres?Можете ли вы предложить (или улучшить мою) схему?

1 Ответ

0 голосов
/ 13 января 2012

Mongodb - отличный инструмент для этой работы. Вы можете в значительной степени использовать встроенную коллекцию, чтобы максимизировать производительность.

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

Например, вместо того, чтобы хранить коллекцию Question отдельно, вы можете иметь это внутри Attendee . Это позволит вам хранить всю необходимую информацию об участнике в одном месте.

- Attendee
     - Info
     - Event_id
     - Questions {
           -Question id
           - Answers [ {                  
                 - answer id 1
                 - or answer text
             },{                  
                 - answer id 2
                 - or answer text
             }],
     }

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

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

Но я предлагаю вам сохранить в поле EventEid_id / name в виде массива, который выглядит

  Event :
        - Info
        - attendees {
             attendee_id : 'xx'
             name : 'Fletch'
          }

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

Надеюсь, это поможет

...