Database Schema Design

Today’s work was mainly adding the “My Polls” page to the application and modelling the database schema for the poll model in Mongoose.

One of the challenge I faced was to find out how I should associate each poll question with the many poll answers it will have. I read previously that mongoDB was somewhat better than relational databases at modelling one-to-many relationships.

For example, in WordPress (a blogging platform that uses relational databases), the posts model requires two tables (post & post_meta) in order to represent all the information. This is because a post may, for instance, contain zero to many tags — and this cannot be stored into a single table without serialization. In mongoDB, however, information like tags could be stored in an embedded sub-document.

This started me reading about mongoDB’s embedded documents. In coming up with the schema, I also learnt a bit about data model design from the mongoDB docs — when it will be better to use embedded data models and when to use normalized data models.

Embedded Data Model
Embedded Data Model – Generally better if you have a one-to-many relationship between entities
Normalised Data Model
Normalised Data Model – Generally used when the relationship is many-to-many and when embedding would result in duplication of data