Ask HN: Why do you hate SQL? | Hacker News Reader

Ask HN: Why do you hate SQL?

6 pointsJustsignedup16 comments

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.

View on HN

> Why do people hate SQL?

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

If you don't use the power of modern relational databases, then all you do is CRUD and it feels really painful and kludgy because, without an ORM, it... well... is painful and kludgy. Most dev's don't think about things like -- what happens if someone pulls the plug during a write? Or what happens if two people update the same record at the same time? They just see ugly INSERT/SELECT/DELETE text strings scattered throughout the code.

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.

Thanks! I think this is a great way to put it. Database locking and such powerful features are incredibly important in multi-process apps. What better way to make critical sections that transcend processes or machines than using a mutex on the data itself (duh).

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.

I am not sure about that. SQL is a tool just like many others and has its pros and cons. I prefer raw SQL when it comes to troubleshooting stuff or running adhoc queries. Nothing is faster/efficient for me than opening up an editor and firing that SQL query, dumping out the csv and emailing it back to my user.

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.

Well perhaps some people get into the hype of NoSQL and then it seems it's a silver bullet. I think NoSQL has its use cases and SQL has its use cases. NoSQL doesn't promise ACID, so any application which requires ACID will probably benefit from SQL. Key-value stores have its benefits in other situations. There are also niche databases, like graph databases, document databases, etc.

I love SQL and I love databases. It's usually where I start any debugging - "what's in the database?" is what my first mentor always used to say when I hit a snag - surprising how often the actual data is simply not being transported to the user correctly.

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

I love SQL, but I'll admit it felt strange when I first learned it. Its non-imperative nature makes it really different than most programming work. It's also harder to break down into units, so you almost need the whole query to spring from your head at once, unlike in a programming language where you can write one line at a time. It takes a little while to adapt to thinking in SQL concepts.

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:

    SELECT  emp.name
    FROM    employees emp
    WHERE   emp.department_id = 5
    ;

Why do you not hate SQL. I suspect the answer is the relational model.

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?

Most people I know love SQL. You should take a look at the Hydra community. They have a lot of relational data that they are storing in a NoSQL database. It's painful to work with but there is a huge reality distortion field in academia when academia embraces the wrong solution.

http://projecthydra.org/

I thought rails took care of the sql for you. create object get database access with out sql. why write crud code if you don't need to?

That is very naive. Rails takes care of model persistence. But what happens when you need to join a ton of data... Sure you can fetch all the records and transform on the web server, or you can ask your database to do it in a fraction of a fraction of the time it would take ruby to do this.

Example:

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.

Nicely put. SQL is the great equalizer.

when /this/could/be/done/with/files/and/folders /so/could/this /or/anything/really

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?

Because we are still querying databases with concatenated strings in 2013.

But that's your project's problem, it's possible to query without ever concating a string or even writing SQL (ORM).

I would really like SQL to be database independent.

Reply on news.ycombinator.com