Hacker News Reader

Comment by taligent | Hacker News Reader

> Real businesses need a data warehouse and SQL is the right tool for that job.

Honestly. I don't think you could be more misinformed if you tried.

Hint: Google "Big Data".

...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.

I've had to deal with a lot of NoSQL advocates whose experience with SQL or relational databases doesn't extend beyond MySQL.

Of course, it's understandable why they have a bad impression of SQL; they've only ever used one of the most inept implementations around.

Those who are willing to try one of the more mature and sensible relational database systems usually see quite quickly the value that such systems provide.

What do you suggest?

Not the OP but I'd say giving Postgres a try is a suggestion.

Beyond a few terabytes of data, Postgres is just as worthless as MySQL, and every other non-experimental SQL option comes with a "call us" price tag.

If there are production-ready options for biggish data other than NoSQL or high priced commercial analytics dbs, please share...

Considering the space requirements of a DB with a properly designed schema, I have to wonder what on earth you can do that generates beyond a few terabytes of data, and how you can make any sense out of it.

Also, your comment is rather ambiguous, I certainly hope you're not calling Postgresql experimental, because that would be laughable; and there are several examples of multi-terabyte databases using it.

>Real businesses need a data warehouse and SQL is the right tool for that job.

SQL is NOT always the right tool for the job.

There are plenty of situations where an Hadoop or a Storm/S4 approach works better. Again it's about picking the right technology for the task at hand.

SQL is an excellent tool for a data warehouse, or any situation where there is value in separating data design from application design. In such situations the infamous o/r impedance mismatch is arguably a good thing.

http://pages.cs.wisc.edu/~jignesh/publ/underattack.pdf

Reply on news.ycombinator.com