Hilarious video...but it reminds me of the painful fact that I know very little about databases so choosing between SQL and noSQL for my web app just seems arbitrary for me. I wish there were some simpler explanations out there.
SQL represents 40 years of experience designing general data stores that work for the widest set of applications. SQL databases solve many very hard problems which you are probably not aware of.
If you jump into NoSQL first you will be reimplementing SQL features in your application code, and doing a shitty job of it because you have experience with data stores that actually solve these problems well.
The reason for the existence of so many NoSQL databases is the rise of web applications and the need to scale massively. However the majority of apps will never need to scale beyond a single well-tuned database server anyway. By the time they do you will have hard problems to solve regardless of what data store you used. The advantage of SQL is that it's a fantastic hedge on the evolution of your data usage patterns because it is designed to support ad-hoc queries well, and the schema prevents bad application code from thrusting your data into chaos at the first occurrence of a small bug.
Realistically if you knew you had to build an app for 5 million daily users, and you knew exactly what it was going to do, then an SQL database very well might be the wrong choice. But in the real world you have a long road ahead before you hit that scale, and you'll have real data to determine what kind of alternate data stores can best handle your load. Personally I'm a huge fan of redis, and its ability to scrape bottlenecks off a MySQL database in a piecemeal fashion.
This is a false dichotomy.
Just because you want to use some unstructured data (which was your original example) doesn't mean you need a new data store that's optimally suited to that. You can store documents just great in an SQL database or in the filesystem.
'Best tool for the job' is an oversimplification.
The nice thing about Mongo is you can query that hash without having to have an index table.
To the parent: thanks for the edifying comment. I do have some experience with SQL and relational DBs, but was thinking of using noSQL for some projects. Your point to thoroughly learn the relational model is well taken.
Okay, so we have a domain object, Foo. Foos represent individual instances of a Foo that a user has, but we want to keep general information about the different standard types of Foo, so we also have a relation between Foos and FooTypes. Oh, and each FooType can have a few different sizes, and some FooTypes are the same sizes as each other, so we also need a FooSize. Not only do we need to relate the number of sizes that each FooType could have, but when a User has a Foo, we gotta know which sized one they have. All this stuff... it's complicated.
It probably would have been much easier for me to have just done each FooType up as a document, with an embedded array of sizes, and then each Foo gets a document, with its own copy of the data. Yeah, there's nothing saying that you can't store de-normalized data in a relational database, but if you're not going to use its features, why not just use the tool that's designed for that use-case?
NoSQL has become an increasingly broad term used to indicate some other storage strategy than traditional SQL databases provide. NoSQL databases tend to operate on a more basic level and omit things like transactions in favor of performance. Schemas are also disregarded to allow arbitrary storage requirements to be addressed with ease; although, you lose the traditional guarantees that a schema can provide.
This is just my opinion, but I think it's a lot easier to setup a clusterfuck storage nightmare using a NoSQL database. If you're unfamiliar with SQL and NoSQL, you're most likely going to end up in a safer and more recoverable situation going with something tried and true like PostgreSQL.
If you're not sure whether you need a NoSQL system, then you don't need one. They serve a use case and performance requirement that very few websites demand. That being said, when the need does arise, they can be an indispensable for scaling out a large website. Like anything else, they're not a magic bullet that you just drop into your storage strategy and go on your merry way. Rolling them out requires lots of planning just like any other large scale deployment does.