[ta0967]

like the yesterday's submission of "Why you should never use MongoDB (2013)" (https://news.ycombinator.com/item?id=12290739), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model.

unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study history of their field and, as a result, don't even recognize they're repeating 50 years old mistakes. sure, SQL has fallen so short of the promise of the relational model it's not even funny, but don't conflate the model with the query language, folks!

[velocitypsycho]

Right tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.

[ta0967]

but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model.

if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single pre-designated root.

both relational and hierarchical databases let you go from department to employee, only one lets you go from employee to their department without enumeration. what purpose does precluding the latter serve?

[pjmlp]

I am yet to fail into this NoSQL trend.

Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit.

Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.

[api]

NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster.

There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only.

[catnaroek]

The relational model does have deficiencies, but the right way to address them is with more powerful schemas, not less. See: “categorical databases”.

(Think about it this way: SQL is Java. NoSQL is your typical extremely forgiving dynamic language. We need a database equivalent of ML and Haskell.)

NoSQL is simply the result of not wanting to think about the logical structure of data. Plain intellectual laziness.

[pjmlp]

And the millennials dislike for not wanting to learn SQL, I think.

You always see how they bash having to learn SQL on those presentations.

[jimbokun]

"NoSQL is simply the result of not wanting to think about the logical structure of data."

NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. Key value stores scale great, at the cost of having almost no query capabilities to speak of.

Now, some developers may adopt NoSQL due to the ease of getting a new project started. But I don't think that was the main motivation of the developers of the major NoSQL databases.

(Although, NoSQL is so broad I'm sure there are counter examples.)

[mpweiher]

Greybeard here.

I suggest you check out The End of an Architectural Era (It’s Time for a Complete Rewrite)[1].

The "failure" of non-relational databases was for specific application domains.

[1] http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf

[candu]

^ this.

To be fair, though, it is genuinely difficult to gauge which technologies are worth adopting. Clearly some are, otherwise we'd all still be writing hand-crafted assembler to optimize drum memory I/O, or perhaps heaps of Perl CGI scripts.

It's also unrealistic to expect the average programmer - hell, even the pretty good programmer - to be aware of 50+ years of relevant research. For starters, many of them can't even access the relevant papers without paying some gatekeeper a whole lot for the privilege. If they could, they'd need a significant investment of time to understand them, especially without ready access to domain experts who can tell them which papers are most worth reading and in which order. (All of these are benefits of graduate student life that are often taken for granted.)

[catnaroek]

Intuitively understanding the benefits of the relational model doesn't require access to scientific publications. Just a little bit of mathematical inclination and, most importantly, basic common sense.

[zinssmeister]

what does PFYs stand for?

[ta0967]

Pimply-Faced Youth :)

[dpacmittal]

Then why are we only singling out Mongo. Doesn't this also apply to other NoSQL stores.

[galdosdi]

Mongo isn't the only bad one but it's kind of humorously become the canononical bad one -- where by "bad one" I mean the kind of NoSQL database you choose just because you don't understand SQL) and not because you have a specific scaling need. A good example of a NoSQL database you'd pick to help with write scaling might be Cassandra (which has schemas and is looking more and more SQL like these days with CQL -- the consistency and data models are just different to allow for writes to scale up)

Not saying Mongo doesn't have any legitimate uses (although I honestly suspect it doesn't, not even the ones listed at the end of TFA, at least not assuming the developer is already well versed in using a good relational database and related tooling. In fact I think I'd be willing to challenge and bet money against a mongo proponent to see who could create "an MVP on a super-tight schedule" faster.)

[JustUhThought]

Amen, brother!!!