Hacker News Reader

Comment by dasil003 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com