NoSQL vs. SQL: The truth about SQL, NoSQL, and NoNoSQL

I got lost with the "is it a * standard" comparison.

I understand the importance of standards, but a standard for a query language is different than a category of data stores. (Also - half the things he talks about further down are very very hard to do with standard SQL and not using any proprietary extensions - see Hierarchal).

Perhaps a comparison that made the left column "RDBMS" would be better... At the very least the 2 standards questions would be set to NO.

Further - there is an awful lot of stuff lumped in RDBMS vs EVERYTHING_ESLE...

"Is it based on a rock solid theory?" Well.. at the very least graph databases are. Others yes and no.

"Will it be around in t 10 years?" Again, given that Neo4J is over 10 years old already and its usage is increasing... I will place a long bet on it being around. Others... again yes and no. Similar for RDBMS. Will oracle be here? Yes. Will Postgres... again yes. But some of the Column-store SQL databases? Maybe. (Also - what does it mean for semi popular software to go away... it takes a really long time. Heck Remember the Firebird database that had some popularity ~10 years ago? turns out they are still shipping code, as of 12-7 anyway. Who knew? Who uses it?)

"Is it even a well defined concept"... Again unfair. The term NoSQL came out of a clustering based on usage, where the results were ("RDBMS/SQL", "everything else") - because at the time "everything else" was the only way to see statistical significance against "RDBMS". Of course its poorly defined. Of course with RDBMS we could be talking about a dozen different technologies with an SQL+extensions interface.

I guess i just get annoyed when people make silly arguments. Not to mention I'm too pragmatic to understand the concept of SQL vs NoSQL. They are tools. Some are good for one thing, others for other things. Seriously - if you take away my graph databases I'll get annoyed. But I'll be equally annoyed if you try to make me use them for storing interesting lookup tables when Postgres is sitting right over there.

tl;dr - We probably need to kill the NoSQL terminology. It's outlived its usefulness.

why does such a stupid article gets upvoted ?

Is it based upon a rock-solid theory Yes [3] No

both should be yes...

Is it well understood Yes No [5]

both depends on the user...

Will it still be there in 10 years Yes [7] Maybe

both should be maybe

Is it an ISO / IEC standard Yes [1] No

Not important to 95%

Plus its not mentioning if MySQL/etc does implement the standard correct.

Ford vs. Chevy! Coke vs. Pepsi! Conservative vs. Liberal! Rah, rah, choose a team, get emotionally committed! Argue your position!

I love confirmation bias fests. Carry on.

The vendor lock-in is true, I suffered from it. But other points make the post look bad. THe comparions should be more mature and give concrete examples, use NoSQL when you need ... and SQL database when you need ... , these are too much opininon based.

I disagree with articles (and people) that are written like this. Reminds me of how burecrautized the sector can be.

99% of database deployments are made by a guy like this and they are hell on earth (thousands of tables, 20+ recursive joins between them, a specification that spans more than 500 tables, "and that's just the 'inventory' database". But hey! the guy must know what he's doing! he's got 'the theory' and Oracle certifications here and there...

At the end or the day the best theory is the one that works. An experienced and honest DBA should propose the tools that better fit the problem given instead of trying to fit the problem within the toolset he arbitrarily prefers.

Disclaimer: I'm using 'he' in its generic gender-neutral form. It wouldn't be nice to get fired just for a quick and casual HN comment.