NoSQL vs. SQL: The truth about SQL, NoSQL, and NoNoSQL | Hacker News Reader

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

nosql-vs-sql.com

32 pointslukaseder26 comments

The problem when you do an opinionated article like this is that is an empty message (It's no going to convince anybody nor going to clear concepts to new comers)

For instance:

"Is it based upon a rock-solid theory"

So a hash table lookup is not based in a rock-solid theory?

"Can it handle relational data models"

Is this an advantage if your data doesn't have relations? (i.e logs)

"Is it even a well-defined concept"

NoSQL is an umbrella term, replace it with Key-Value data store or with a Document store and you will see it is pretty well-defined.

And the list can be extended...

The mainly problem with NoSQL databases is that they are keep being used in places where a relational database would make more sense and after failure those people are very vocal about it. At the end of the day is a tool and you will be fine in using it as long as it is the right tool for your need.

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.

I'm still waiting for any NoSQL technology to produce masterpieces of algorithmic knowledge as the guys at Oracle (or Microsoft, IBM, etc.) do. Have you read Tom Kyte's metadata matters? http://de.scribd.com/doc/28708969/Metadata-Matters-by-Tom-Ky...

This isn't just about Oracle certifications. This is about databases that can actually handle the "hell on earth" complexity that some systems simply have. Or do you think you can run a bank or an insurance company on a key-value store, implementing their immensly complex business rules with a couple of hash tables?

Granted, every problem can be solved with the appropriate tool and some NoSQL tech is indeed appropriate for some problems. But then again, SQL is actually a pretty good tech for 90% of the problems.

IMHO and probably limited experience, all data problems as data size and concurrency approaches infinite become the same problem, and that problem is more easily solved with a KVS rather than with infinite RDB tables.

To me, KVS and RDB are just two sides of the same coin. If you start modelling properties your DB will look like a RDB, if you start with objects first your DB will look like a KVS. I prefer KVSs because it's more natural for me to think of everything that way.

Here I'm abusing the scope of the word KVS, what I pretend to mean is some kind of "document" store accessible/sorted by keys.

Yes, I know that Erik Meijer tried to claim that KVS (NoSQL) and RDBMS are two sides of the same coin: http://queue.acm.org/detail.cfm?id=1961297&repost

To me, quite frankly, his article sounded more like a pro-LINQ marketing campaign than anything else :-). No wonder he's propagating duality between SQL and NoSQL (coSQL) when he planned on creating a company called Applied Duality Inc...

Didn't knew of that article, thanks.

Nice one but yeah it kind of sucks that the theory is used like a preamble for trying to sell you LINQ

The fact that you would even theoretically be fired for expediently using a gender-specific pronoun is beyond ridiculous. Unless, of course, you're part of the political correctness secret police.

Haha, haven't seen the news lately?

Check out what happened w/ node, also the guy that made the 'dongle' joke.

The bias is very obvious. There is a leaning toward SQL. While some of the things may be true there is a heavy focus on standards here & less so on performance & capabilities.

Looks like its to push the commercial product on the bottom of the page.

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.

> We probably need to kill the NoSQL terminology. It's outlived its usefulness.

On a more serious note, this is probably the main point of that website.

JooQ is Apache 2.0 licensed. He's selling support and drivers for commercial databases.

This reminds me of the Stephen Colbert quote, "Reality has a well-known liberal bias."

Depends a lot on who you surround yourself with.

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.

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.

It's not really news that nosql is a vague and unhelpful term.

if you lump together things like couchdb, a document database built for replication and Casandra a wide column database built for big data storage, pretty much everything is going to be a maybe as those databases are more different from each other then they are from SQL. The real cheat sheet for SQL vs nosql is:

A concept that refers to something specific: SQL 1, nosql 0

> A concept that refers to something specific

It says: Is it even a well-defined concept: SQL 1, NoSQL 0

Feels somewhat biased to me, only because it claims to expose the truth. It's very easy to only include metrics for things that look favourable and the points made there don't really help me as a developer to choose the best one for a project. Questions I think are valid when looking at NoSQL vs SQL are:

- Does it enforce a schema?

- Can you store nested data structures in your record?

- Can you perform joins?

- What replication models are available?

- What patterns are available for high performance read/write operations?

- Storage implications?

Scores like "Is it something new" I don't see serve any purpose. Why is it important if it's new or not? If it's new and therefore not mature, then simply say "Is it mature". If it's that there is a lot of third party support, then say that.

The problem is a lot of the truth comes down to the database vendor, not the general concept. SQL is a known standard, but what is NoSQL after all? As there's no standard, what are you actually comparing i to? Bottom line is, all results are moot if the database server I'm using has inherent limitations.

It's like comparing a hammer and a screwdriver when you really like screwdrivers using comparison points such as "Does it put it screws?" Point being, they're not tools designed to solve the same problems.

Reminds me of the old joke comparing iPhone 3G and Nokia 3310.

* MMS: Iphone: No, Nokia: No

* Bluetooth: IPhone: No, Nokia: No

* Making Videos: IPhone: No, Nokia: No

* Video calls: Iphone: No, Nokia: No

* Memory cards: IPhone: No, Nokia: No

* Colour display: IPhone: Yes, Nokia: No ;)

I am tempted to write a book on this now. Model driven, event driven and generally AOD absorbs complexity much better than the traditional OO or procedural only models (and obviously the building blocks are procedural/OO after all). NoSQL (document based approach) is made for model driven, event driven AOD environments.

While I partially agree with you, to me the ease of making summaries of data across different sets, makes SQL a better choice for where higher order calculations are required. Writing a distributed map reduce query in erlang is both harder to make fast, and harder to understand.

For something like static html pages, for say a source control web app like Github, Riak or some other document store is a great choice.

But for something like a invoicing/accounting app like FreshBooks, where you need to summary and filter across multiple accounts, invoices, staff, etc., then SQL is much easier to build a OO backed system. (Although there would still be events in there as well, like notification systems, etc.)

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.

A bait headline with empty content.. no wonder it gets upvoted in HN

How is NoSQL both very old and immature? Can someone explain to me the definition this is using of "mature"? Is BigTable mature software?

Reply on news.ycombinator.com