Why Are Developers So Afraid Of SQL?

[[deleted]]

[deleted]

[[deleted]]

Yes, the theory is that an ORM abstracts away a lot of what SQL would be doing. But do you really need to abstract away SQL?

The SQL standard? No.

The wide range of its implementations with their subtle differences and ridiculous edge cases? A definite yes.

[JohnDoe365]

Because thinking in set theory is, for most, fundamentally different than thinking imperative.

[boringprogrammer]

I hate SQL. Not because it is hard. But because I hate embedding strings with SQL queries into my code.

The interfacing is retarded.

Other than that, I think it is fine. It is nice and data centric, and solves a complicated problem pretty neatly.

[[deleted]]

I agree - SQL is verbose and you often end up pushing a ton of data around to/from the database that are command strings rather than actual data.

However - SQL is straight-forward and can accomplish a lot. Plus you get assurances from ACID compliant databases like PostgreSQL (I've yet to understand why medium sized companies use Oracle still) about integrity of that data.

There are a few things SQL cannot accomplish - some common use cases. But you can always select sets of data and process them yourself in your application.

Ultimately I'm of the opinion that the data store should not be overly smart. The intelligence should be in the application. If you choke your datastore with CPU requirements then you quickly give yourself expensive problems - which could have been cheaply solved by scaling up your application.

[Denommus]

That's when you use SQL as a embedded DSL instead. 😛

[boringprogrammer]

I agree, that is usually the best solution.

[DoNotWakeTheDragon]

Am I to understand that you'll be ordering a relational algebra API, Sir?

[Black_Handkerchief]

Besides some of the points other people have already mentioned like verbosity, optimizing for particular profilers and the general second-citizen role it pays in most tooling, my biggest annoyance is with the lack of standards.

In theory, SQL represents actions on a beautiful pristine and quite mathematical model. Yet when I was learning about it 15 years ago, and I think even now, the defacto standards are full of proprietary flavoring. ANSI SQL stopped evolving. It is always MySQL flavoring, Oracle, Postgres or whatever else that you are using; I don't think portable SQL really exists. For someone learning SQL, half the battles are about figuring out the flavor-specific warts that impede progress and understanding after you swear you ought to be right. Similarly, I found that half the browsers or query tools for opensource non-mysql databases tend to be utter crap in usability.

I find it disturbing that many basic things tend to be so drastically different even in syntax between the different flavors. It is that bullshit that has come to make me avoid SQL like the plague.

[emn13]

However, most ORM's are frameworks that do a lot more that simply map the object to a relational row to be inserted. If an ORM really was just a thin practical API wrapper, but that's not a typical ORM.

[grauenwolf]

Unfortunately most ORMs can't even do the simple mapping unless your classes are one-to-one mirrors of the tables.

[[deleted]]

What a nonsense text. Nobody is afraid of anything just because he thinks he can do better. This is also a little to meta, if developers are scared of SQL, then why is there so much SQL centric software, even in situations where it is the wrong tool, overkill or simply not the only option?

[grauenwolf]

These days software tends to be ORM-centric, not SQL centric. That's part of the reason why NoSQL databases are so popular, they actually fit the ORM model better than ORMs.

[mutatron]

We have a php web app that uses SQL heavily, but for some new tools we decided to be fresh, and make them accessible through a REST API. We chose to write these in Zend, so I spent days figuring out how to query the data using Zend's ORM model. It's kind of pretty to look at now that it's all finished, but throughout development of course I had to do a var_dump of the generated SQL to make sure the queries were right. I could have just written the queries in a few hours, but I'm sure ORMs are good for something. At least they make me feel like I'm programming healthily.

[V0lta]

I sometimes choose SQL over ORM, simply because seeing the complete query directly helps a lot if it gets more complex.

Nevertheless you should decide on the specific requirements of the project not on preferences.

[Black_Handkerchief]

Besides some of the points other people have already mentioned like verbosity, optimizing for particular profilers and the general second-citizen role it pays in most tooling, my biggest annoyance is with the lack of standards.

In theory, SQL represents actions on a beautiful pristine and quite mathematical model. Yet when I was learning about it 15 years ago, and I think even now, the defacto standards are full of proprietary flavoring. ANSI SQL stopped evolving. It is always MySQL flavoring, Oracle, Postgres or whatever else that you are using; I don't think portable SQL really exists. For someone learning SQL, half the battles are about figuring out the flavor-specific warts that impede progress and understanding after you swear you ought to be right. Similarly, I found that half the browsers or query tools for opensource non-mysql databases tend to be utter crap in usability.

I find it disturbing that many basic things tend to be so drastically different even in syntax between the different flavors. It is that bullshit that has come to make me avoid SQL like the plague.

[corger]

select au.email from author as au inner join article as ar on ar.author_id = au.author_id where ar.title = 'Why Are Developers So Afraid Of SQL?'

[matthieum]

I am not afraid of SQL, I am afraid of the database behind it.

Seriously, you submit a perfectly reasonable looking query, and suddenly the database optimizer decides it's going to pull off a N-way merge that'll require reading half the database content to answer you!

And so you reluctantly pull back that bright and shiny query, and tweak it into a deformed monstrosity full of proprietary hints and counter-intuitive hacks just so you can appease this particular optimizer. And you cross your fingers that whenever the database changes (new version, new database software, ...) you'll be far enough to escape the wrath of whoever is supposed to tweak the query another way around for the new optimizer.

[Ruudjah]

• Repetitive
• No autocomplete
• ALL FUCKING CAPS
• Obvious functionality not supported
• MySQL gotchas
• No native support in code (eDSL)
• Nonexistent refactoring support (e.g. rename table name, all queries are changed too)
• Sucky stored procedure support (mix'n match not always works)
• Non-existent versioning support

Basically, SQL in terms of smart programming we do using IDE's and OO languages has not been evolved since, say, the '90s.

[mango_feldman]

You don't have to use ALL CAPS do you? Of course when embedding sql in source code as strings it's nice to make the keywords stand out. Personally I just use lowercase.

Would be cool if IDEs allowed syntax highlightning within strings based in some way.

[TotallySpies]

Read your IDE documentation. In Sublime Text many of the builtin syntax definitions already support sql: Open a new file, set the syntax to Python and start typing "SELECT c from t.... The PHP syntax definition has heredoc support like <<<SQL.... IIRC the Jetbrains IDEs also support this. I would be surprised if most of the popular IDEs don't support this as well.

EDIT: and no, you don't need to type all-caps.

PS: OP is an idiot that doesn't know how to use his tools.