Ask HN: Why do you hate SQL?
Background: I've used SQL for 100% of my programming career. I find it to have quirks in a similar way that Java, Ruby, C, and any language you love have. SQL is not in any stretch of the word good for programming complex things, but it appears to be amazing at asking a computer to give you data in a way that you would find useful. At times I was even able to make an oracle database perform really well on really poorly structured or awkward data.
So the question: Why do people hate SQL? And I am not talking about (kind of I am) the NoSQL movement. I totally get that these NoSQL databases have advantages in scaling or performance in exchange for a guarantee that ACID compliant databases have.
I ask because whenever I mention SQL to ruby developers, I get a sense of aversion.
16 comments
[ 1.6 ms ] story [ 84.1 ms ] threadExample:
Select all users who have an entry in their shopping cart with an order greater than $200 and tally up how many users there are by state.
Databases can usually do this with a few index lookups and give you results in seconds from hundreds of millions of records. There are no objects to map, just data and math. Then boom you get like 50 rows returned with a state and a tally. Try selecting all those tables building orm objects and transforming that data on your rails app.
And that's always been my take at it.
I think most Ruby people are front-end and don't really have to deal with data (and there is nothing wrong with that).
So I suggest that you ask a different audience? Ask people who (1) work server side and (2) deal with data.
In other words, it is like asking a jazz musician why they like Mozart but not Beethoven. Not much information there.
Having said that, there are times when you just don't care, performance trumps correctness (caching or other fuzzy indexing).
Cool thanks for the insight.
If your work involves lot of troubleshooting, adhoc querying etc, SQL is a life saver when it comes to relational databases. I don't want to spend time writing a python code with ORM to do these kinds of queries.
There are two (EDIT: three, really) kinds of anti-SQL people I've encountered:
1. People (often SQL experts) who dislike SQL, or at leats prefer/propose alternatives to it, because it has features which make it less-than-elegant in dealing with some problems which are fairly straightforward to address under the mathematical set theory underpinning the relational model. [1]
2. People who, for a variety of reasons (some well-considered and valid, some less so) prefer not to use relational data stores at all. (E.g., the NoSQL movement, which, despite the name, is really about alternatives to relational-model-datastores, not alternatives to the SQL language for relational datastores.)
EDIT: And, probably most relevant to your observation that:
> whenever I mention SQL to ruby developers, I get a sense of aversion.
3. Application developers who have a strong preference for working exclusively in one preferred language, and don't really want to deal with anything outside of that.
[1] Hugh Darwen and C.J. Date are prime examples here; see, e.g., http://www.dcs.warwick.ac.uk/~hugh/TTM/HAVING-A-Blunderful-T...
Perhaps another reason is that SQL formatting style is less unified, and stringing the whole query onto one line is a mess. Here is how I like to write it:
As a language, SQL is terrible. But it (poorly) implements enough of the relational model that it's still incredibly powerful.
What really puzzles me is why, when there is constant innovation in system and application programming languages, databases are still stuck on the equivalent of COBOL. Why isn't there a modern relational language?
http://projecthydra.org/
instead, you get /404-error
if the db abstraction layer and URL rewrite engine is having a problem..
thousands of lines of code just to mimic a filesystem? why?
I notice that devs who love their ORM of choice tend to rally against SQL itself, but I for one, would rather see a SQL statement - abstraction to an ORM is great of course because it keeps you in the paradigm of your chosen language, but it sucks because every time you move to a new framework, you have to re-learn how to create those complex pieces of SQL you've been using.....