

NoSQL vs. SQL: The truth about SQL, NoSQL, and NoNoSQL - lukaseder
http://www.nosql-vs-sql.com

======
pmelendez
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.

~~~
almosnow
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.

~~~
lukaseder
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...](http://de.scribd.com/doc/28708969/Metadata-Matters-by-Tom-Kyte-Oracle)

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.

~~~
almosnow
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.

~~~
lukaseder
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](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...

~~~
almosnow
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

------
Tarang
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.

~~~
sophacles
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.

~~~
lukaseder
> 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.

------
cognivore
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.

------
lampe3
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.

------
cwmma
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

~~~
lukaseder
> A concept that refers to something specific

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

------
martin-adams
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.

~~~
michaelmior
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.

------
pkolaczk
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 ;)

------
bmorsh
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.

~~~
3pt14159
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.)

------
CSDude
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.

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

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

