Comment by dasil003 | Hacker News Reader

Comment by dasil003 | Hacker News Reader

Parent Full thread

First learn SQL and the relational paradigm.

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.

NoSQL isn't just about scale. Sometimes, modeling data relationally is a real bitch, and a document store makes more sense.

It's not a huge win though, because most of the time you still do have some relational data, and there's no reason you can't dump documents in an SQL database. The fact that the interface is new, shiny and slightly more elegant for this simple degenerate use case doesn't carry much weight with me.

Real admins use the best tool for the job, anyway. "Polyglot persistence" is where it's at: You keep your sessions in Redis, you keep your news feed in MongoDB, and you keep your credit card details in Postgres.

This is a false dichotomy.

There needs to be a threshold of utility before you add an additional data store to your application.

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.

This is the important bit. Just about every company or web app will have a bunch of relational data and therefore an SQL database of some kind. And storing key-value pairs in an SQL database is really not that hard or inconvenient or slow or whatever - it's gonna be 'good enough' for just about everyone. Why bother supporting an entire extra dedicated KV store when the SQL DB I already have will work just fine?

'Best tool for the job' is an oversimplification.

And lots of NoSQL databases do have these kinds of value-add features. For example, FourSquare writes data into Mongo (and Postgres, as well, actually...) because it has location features built into it.

http://www.mongodb.org/display/DOCS/Geospatial+Indexing

Sure, you can create a massive json hash and store it in a sqldb field. However, most sqldbs that I'm aware of do not support searching that massive hash. You need to come up with index tables.

The nice thing about Mongo is you can query that hash without having to have an index table.

Yeah, the reason I was thinking of using mongo is because I have to write a simple posting app (i.e. allow for blog or twitter style posts with tags) so defining a relational schema seems like overkill to me. But I can't be sure.

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.

Knowing the relational model is really important, but you're also going to have to unlearn it in order to do a good job with NoSQL. It's a totally different set of rules.

Even here, you might be surprised by how limited some NoSQL stores are. E.g., if you have a requirement like "find the first 20 blog posts written by X after this date."

Can you give one instance of this?

This sort of thing is hard without getting into tons of specifics. Now, I was raised on good old normalization and all of that, but it doesn't mean that I'm a master at it. It's possible that there's a good way of relating this that I'm just overlooking. Or maybe I should have just denormalized it from the start.

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?

Reply on news.ycombinator.com