Live data from Hacker News

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

nosql-vs-sql.com

1–10 of 27 posts

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

#3
post #2

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.

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

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

#4
post #2

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.

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

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

#5
post #2

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.

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

Depends a lot on who you surround yourself with.

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

#6
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.

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

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

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

#8
post #6

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

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

#9
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.

Post reply on HN