Question

I’m writing a basic event registration web application and I’m wondering whether MongoDB would be a good choice for the datastore and if so, how to model my domain. The app will be very small, so performance and scalability is not a concern, however when I started to think out the model in RDBMS third-normal terms it sounded quite complicated for what it is and from the bits and pieces I’m picking up about Mongo, sounded like a typical use-case. Is it?

The Application

The app allows creation of events, and for attendees to sign up to those events, giving their name, date of birth, etc. Easy, two tables with n:n join. The tricky part is that the organisers wish to be able to ask attendees of certain events for information particular to that event, for example on one event there might be a question about their accomodation preference. I narrowed it down to two types of question: those that require to select from certain options (will be an HTML select list) and questions which allow free-text answers. By the way it’s a Rails app in case that matters.

Traditional RDBMS

In an RDBMS I would need perhaps a table for Constrained Question (where answers are from a list), a table for Answer Options, a table for Free Text Question and Free Text Answers; and to appropriately link this all up to the event and the atendee via a Signup. If you think about it the links between the tables are rather complicated!

Mongo

Would this be simpler to model in Mongo? I thought that perhaps besides the Attendee and Event collections, there could be a Question collection which has its allowed answers embedded, if there are no answers then it’s free text. A Signup collection that relates an Attendee to an Event and references the id of the relevant Question, and embeds the text of the answer? If the text of an answer option ever changes it might get complicated… but I guess that’s the tradeoff of Mongo.

Is this a good use case for Mongo on should I stick with Postgres? Can you suggest a (or improve my) schema?

Answer 1

Mongodb is a awesome tool for this job. You can pretty much utilize the embedded collection here to maximize the performance.

Your current schema is perfectly fine. By tweaking this a little bit with embedded collections , it will be a blast.

For instance, instead of keeping the Question collection seperately, you can have this inside Attendee. This will let you store all relevant info about the attendee in single place.

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

Also you can cache the frequently used data about the attendees inside the Event collection.
This will be immensely useful for quickly displaying home page data.

For example, you may need to display the users who are attending the event and their count in the event home page. To do that you need to first query the event and query the Attendees.

But i suggest you to do store the attendee_id/name inside the Event as an array, which looks

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

So you can populate the event home page with a single db call to Event collection. Because you can get a minimum info to be displayed about the user and total user count for an event will be retrieved here itself. You can query the attendee when you need to display more info about the user like his question/answers.

Hope this helps