Question

Right, so I’m about to start writing a blog for my website using Node.js (as much as a learning process as anything), and I’ve been fiercely debating with myself which of either MySQL or MongoDB to use.

Searching around has produced a few "how to write a blog in Mongo" guides, but they don’t seem to cover the sort of things I’m running into issues with. Here’s my dilemma:

If I was to use MySQL, I would imagine my schema being something along these lines:

Posts:

ID, USER, DATE, TITLE, TAGS

Comments:

POST_ID, USER, DATE, MESSAGE

Users:

ID, SCREEN_NAME, IMAGE_URL

So, each post has associated comments, and posts and comments have associated users. The advantage is that if a user wishes to change their screen name, or image, only one row in the users table needs to be updated. However, offhand I’m not sure however how I would, say, get all of the posts containing X tags, unless perhaps I have multiple fields for multiple potential tags?

Alternately, using something like MongoDB, I was looking at formatting it like this:

Posts collection:

{ 
    {
    _ID: something
    USER: {id: id, name: "screen name", image: "image_url"}
    DATE: ...
    TITLE: ...
    TAGS: [tag1, tag2...]
    COMMENTS: 
         [
         {USER:someone, DATE:something, MESSAGE:"hi"},
         {USER:someone, DATE:something, MESSAGE:"another message"}
         ]
    },
    {
    _ID: something,
    USER: {id: id, name: "screen name", image: "image_url"},
    DATE: ...
    TITLE: ...
    TAGS: [tag1, tag2...]
    COMMENTS: 
         [
         ...
         ]
    },
}

So, comments are embedded within each post, which seems natural.

Here, one query can retrieve me all of the posts which match which is great. On the other hand, what if I need to update the screen name or image that a user uses? It seems hard to dig into embedded objects within a given document, let alone update all of the relevant records across every post.

I could move the comments into a separate collection to make them more accessible, but I’d still be faced with doing lots of updates on things like screen names.

So…

Essentially, I would prefer to use MongoDB, as what it can do, it can do very easily, and getting to work with one language across the board is nice. However, I cant help but feel that I need to adopt a relational approach in order to get things done "properly".

Has anyone had any experience doing something similar in either, or both languages?

What is your take on this, and specifically how do you handle the relationship between users and comments/posts?

Thanks in advance for any help 🙂
James

Answer 1

This question most definitely does not come down to performance since both MongoDB and SQL would pick a small dataset such as this the exact same way and so there would be no real measurable performance gain.

The main idea of MongoDB in this situation is the ability to nest many tables within one and so making less queries to update your information, for example, instead of querying 12 tables you just query one. Not only that but sometimes the schema can be more natural to how you actually use the data.

I would change a few things in your schema:

USER: {id: id, name: "screen name", image: "image_url"}

This should just be an ObjectId that relates to a user row and again in the comments:

{USER:someone, DATE:something, MESSAGE:"hi"}

use an ObjectId for the USER field. These ObjectIds would relate to a user collection. Also take out those capital letters, I sense that will be a pain to code around.

As for dealing with relations:- you nest repeatable information to an entity as subdocuments (which would normally be normalised out in 1st NF), however that doesn’t mean you should nest to infinity, 3 levels maximum is normally advisable for querying compatibility also bare in mind the boundaries of app entities such as blog, post and user.

Now you have to manage none nested relations such as the blog and user row (since posts will have comments etc nested). The way to solve these relations is client side, since MongoDB has no relational ideals (it’s a RDB heretic).

You would simply do what MySQL would normally do server-side client side, of picking out the user individually and then picking out the posts based on that user id instead of picking out a huge result set of each row being a join between user and post tables.