Relational Database – What Does ‘Relational’ Imply?

The main reason for choosing a NoSQL database the last years have been Availability. For companies like Amazon, Google and Facebook an hour of downtime or so isn't acceptable. To achieve high availability you need to reduce single-point-of-failure, that means you need to use a distributed system with multiple computers in case a computer crashes, the service is still available.

Traditional Relatione databases isn't very good in a distributed multi-master setup. That's why NoSQL has been so popular lately. So if you need high availability you may choose a NoSQL database like Riak, Cassandra, HBase, S3 or BigTable.

There is a good blog post about Amazon's Dynamo that is a good introduction to distributed NoSQL databases.

Now, the NoSQL term is very broad so there are many NoSQL databases that aren't distributed. But they solve other problems. E.g. Neo4j - a graph database are good on a type of queries that traditional RDBMS aren't optimized for. Or as in your case a document database, where you don't have to change the schema if you want to add some fields for some documents. In other words a document database is good when most posts (documents) has different fields so a relational table with predefined columns isn't usable.

However, most of the NoSQL databases are not as flexible as traditional RDBMS databases are, so it's a good choice to use a traditional RDBMS database until it can't solve your problems anymore.

If you choose to maintain a hierarchy in a relational database, you need to look into the Nested Set design pattern. (See Wikipedia)

This model involves some programming, and it involves some overhead at insert or update time. The benefit comes at retrieval time. Retrieving the path or the subtree for any given node is easy and fast, when compared to the traditional approach, called Adjacency List.