Hacker News Reader

Comment by mkosmo | Hacker News Reader

I've asked many devs why they chose Mongo over a RDBMS. They can never give me a technical answer. It's always 'it's cool' or because they just read something about it on some non-technical blog.

It usually only takes me a minute or two to ask them a future function question that's not reasonably attainable (and performant) with a NoSQL solution... so they wind up going back to whatever RDBMS is their standard.

View on HN

> It usually only takes me a minute or two to ask them a future function question that's not reasonably attainable (and performant) with a NoSQL solution.

Curious if you have an example of this.

Will you ever need to join X on Y?

And suddenly I have flashbacks to dev meetings where we were deciding if we should do joins in Python or denormalize our data across a dozen tables because we needed Cassandra, obviously.

The only reason I can think of is not wanting to deal with migrations when you are changing schemas all the time. As long as you can keep all of the previous schemas in your head and account for that in your code, you don't have to migrate anything.

It's not really a very nice way to go long term, but can be convenient when prototyping.

I think CouchDB had some real potential, but Mongo is like Couch without the interesting parts. Couch was like indexes on crack. You can make an index that does arbitrary transforms. Sad part was, it didn't have any smarts to pre-cache those "views" in an intelligent way, which to me would be the whole point of that endeavor. I think something like it will come back eventually, but it's still a very research-y idea.

Biased opinion, but Couchbase is like CouchDB on crack. So, by extension... (Disclaimer: I work for Couchbase.)

Huh. I was starting to prototype some stuff with CouchDB when the transition was happening and when I looked at CouchBase it seemed like something important was being abandoned but now I can't recall what I thought that was. I'll look at it again.

As an aside, what I really wanted from CouchDB was that I could create a view and as I inserted new documents into the DB, CouchDB would automatically generate the new view documents so when I query the view, everything is already precached.

At the time I needed to implement a fire hose listener that would would sip inserts and decide which views with which parameters needed to get called, and then just hit them with REST to do the precaching. It seemed cumbersome, but it sort of made sense why it would be hard for the DB to know what queries on the view were implicated by a new document.

Has CouchBase improved the story there at all? To me that was always the killer promise of CouchDB... Storing documents in a format that made sense at creation time and having arbitrarily complex views on that data... without a cache hiccup. But that "without a cache hiccup" never seemed to quite materialize as a first class feature.

I don't think I ever heard a good technical reason to use a traditional RDBMS. And as a default choice it is not a very good one, when something distributed can deliver an easy to maintain resilient solution pretty much out of the box.

I'm sure many can be produced, but the first off of the top of my head is accessibility for quasi-developers. If you ever want to hire some analyst roles you are going to find that it's a lot easier to get people that have at least some familiarity with SQL instead of having to train them on whatever custom NoSQL flavor you are using.

Of course you could solve that by having an ETL process dump your stuff into SQL (we keep our stuff in Cassandra and dump it into SQL for analysis), but that's another ETL you need to keep track of and in our case we use a quite complex data model and the ETL only supports a subset of it.

Another one just off the top of my head is joins. Some data is just inherently better suited in normal form.

Reply on news.ycombinator.com