
Ask HN: Why do you hate SQL? - Justsignedup
Background: I&#x27;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.<p>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.<p>I ask because whenever I mention SQL to ruby developers, I get a sense of aversion.
======
dragonwriter
> 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...](http://www.dcs.warwick.ac.uk/~hugh/TTM/HAVING-A-Blunderful-
Time.html)

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

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

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

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

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

------
pjungwir
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
        ;

------
penrod
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?

------
throwawayyxy
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/](http://projecthydra.org/)

------
sharemywin
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?

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

~~~
groundCode
Nicely put. SQL is the great equalizer.

------
cdsrv
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?

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

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

------
Proleps
I would really like SQL to be database independent.

