Live data from Hacker News

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

nosql-vs-sql.com

21–27 of 27 posts

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

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

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 lea…

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

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

#22
post #12

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…

> A concept that refers to something specific

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

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

#23

Earlier quoted context omitted.

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 O…

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.

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

#24

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"…

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 O…

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.

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

#25

Earlier quoted context omitted.

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 O…

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 thi…

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.

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

#26

Earlier quoted context omitted.

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 thi…

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 becaus…

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

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

#27

Earlier quoted context omitted.

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 becaus…

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

Post reply on HN