Why Choose NoSQL and Document Databases over RDBMS

This screencast by Michael Kennedy shows you the stark contrast in simplicity between an application using a relational database and one using a document database such as MongoDB, CouchDB, or RavenDB. You should have a good idea why you might choose NoSQL over databases such as SQL Server, Oracle, or MySQL after watching this short video.

[dunwan]

Using a RDBMS I would create four tables as follows;

#Task
TaskId (primary key)
UserId (foreign key User.UserId)
Tags

#User
UserId (primary key)
UserName
...

#Activity
ActivityId (primary key)
TaskId (foreign key Task.TaskId)
ActivityTypeName
StartTime
CompletionTime
FileData
FIleName
Completed (boolean)
FavoriteScore

#ActivityType
ActivityType Name (Primary key, unique)
description

The design with 15 tables (on the fifth slide) isn't practical.

[sskgrs]

15 tables for managing tasks :-)  Is it hyper normalized to 5th normal form??

To be fair to RDBMS, I would say your tasks are probably managed in about 5-6 tables.

[douglasgb]

The initial "flawed" relational schema is largely the mess it is due to a poor schema design... Rather than it being a mark against RDBMS's

[benzflynn]

3:58 Says there are 15 tables plus 19 relations between them. I see just 14 tables on the diagram.

[selfish]

why not to put all your staff in 3  tables instead of 15 in SQL

[Barbara_Salesch]

Whether or not it's faster totally depends on what your software queries from the DB. Simply saying "NoSQL is faster" is a bullshit statement. Depending on your model, it will be faster for certain queries, but therefore you will sacrifice speed for other queries.

[jdev_fr]

You over simplify and lose credibility over that.... your 3 collections noSQL db won't be able to do as much as the 15 tables SQL one: for example it will be inefficient to work on activities as they are embedded in multiple different documents.

NoSQL do have pros and cons in the end designing your model is as critical and "difficult" in both SQL and NoSQL specially once you go a bit further than basic useless examples.

I do use both and try to convince myself I did the right choice every time but the truth is that nowadays if you don't deal with millions of records both SQL and noSQL do the job fine.

Yes noSQL seems more friendly to read but sometimes making a good 1-N or N-N relation can be a real headache if you're thinking about ease of access and convenience of requests.