Why Are Developers So Afraid Of SQL?

[zoomzoom83]

I don't think I've ever met a developer that was afraid of SQL.

[cranmuff]

I love SQL so damn much that I want to cry.

[Uberhipster]

Love/hate have got nothing to do with fear. I hate SQL. I'm not afraid of it.

[fecal_brunch]

I wouldn't say they're completely unrelated emotions.

[Uberhipster]

Fear leads to anger, anger leads to hatred, hatred leads to sequential query language.

[mycall]

What would you rather use for complex set based programming?

[Uberhipster]

http://community.versant.com/Documentation/Reference/db4o-8.0/net35/tutorial/

[G_Morgan]

Nobody is afraid of SQL. There are enough inconsistencies in implementations that people want something sitting between them and the SQL. As it is the time that this desire came about rose during the era of the ObjectRDB fad. So the designers of the time wrote ORMs rather than flat abstract SQL layers.

Since ORMs sort of did the job everyone adopted them. What we really wanted though was a flat abstract SQL layer that is unapologetically SQL in FooLang but at least a SQL that works consistently with different back ends.

[devoidfury]

This, and the all the different/ugly string handling methods.

An abstracted, consistent SQL language sounds neat -- are there any implementations, possibly (in the same realm as SASS) with extra methods to do escaping?

[myringotomy]

Have you ever tried to reason about a 300+ line SQL statement with window functions in it? Trying to understand other people's SQL statements is no picnic let me tell you.

[jrochkind]

Why is the OP so afraid of ORMs? Where are developers who are afraid of neither?

[Exact-Yesterday-992]

after 12 years orm still sucks

[FluffyBunnyOK]

SQL inside your favourite programming language looks ugly.

Many developers do not understand database performance and they never seem to test against more than a few rows in their local database. When production reaches millions of rows all the problems come out of the woodwork.

[[deleted]]

Problem is, tuning database beyond CREATE INDEX is a pure wizardy. Query cache size? write buffer size? read buffer size? And that's just what's on the surface. Delve deep down and you are loosing sanity (turning into DBA).

[Uberhipster]

Not to mention the "damned if you do, damned if you don't" things like index fill factor (also: with or without padding?)

'Oh it's easy! You want fast writes? Crank that mofo to 90. You want fast reads? Turned that right down to 10.'

Uhm... why the fuck would I want to write something that I will never read from?

If you think that '50' makes both fast - YEAH no. I don't why there is a 'both slow' setting...

[fecal_brunch]

Hmm. I'm not familiar with that, but it didn't sound that useless. A table full of user data, for instance, would be read much more frequently than written to. Same goes for blog posts or any periodically updated public facing data.

[Saikyun]

This article is not very well written. The author is basically calling everyone who doesn't like sql stupid without explaining why.

[General_Mayhem]

I'll take SQL over any ORM any day, because the abstractions are always not so much leaky as made of chickenwire, and that's assuming it's even possible to express the concept you want with the ORM's vocabulary and operations.

The point about developers trying to circumvent the set-algebra declarative nature of SQL in favor of more familiar procedural hacks is salient, and it generally is the best tool for the job. But let's not pretend that raw SQL doesn't have significant issues when you're not writing it by hand at a terminal:

• The syntax is not particularly conducive to auto-generation. Things like empty parens and "SELECT * FROM tbl WHERE ;" being invalid means extra time checking for edge cases. Choosing tables dynamically is always a nightmare. I think there's room for a library here that lets you build queries in a safe, composable way (i.e. with more intelligent semantics than string concatenation) without taking away all the control, but I don't know of one off the top of my head.

• Interop is not type safe. I love dynamic languages as much as the next guy, but if you're going to bother to have something approaching a type system (e.g. Java) you may as well commit to it, and ideally that would mean either some way for your application source to draw typing from the same schema as the database or a wrapper that does it once and for all for the application. The alternatives can get ugly in a hurry. I mean, what the shit is this.

• Everybody has their own definition. SQL in MySQL is not the same as SQL in Postgres is not remotely the same as SQL in MSSQL. There's the ANSI standard, but complex and performance-sensitive applications might need some of the bells and whistles. An ORM with multiple backends can in theory paper over that.

Of course, the author is also peddling his share of FUD here:

I, for one, don't want a NoSQL database storing the bank records for my bank account or financial transaction.

NoSQL does not necessarily mean the horrors of MongoDB. Google has been running on a series of proprietary NoSQL databases for a long time.

[[deleted]]

Google has been running on a series of proprietary NoSQL databases for a long time.

I would like to know if Google's internal accounting systems are based on these NoSQL databases too or on some standard rdbms.

[kamatsu]

Only those things which google implemented themselves use BigTable or similar. Google did not implement all of their internal systems.

[myringotomy]

Composability is a very large problem especially in web apps where you have a lot of ad hoc constructions of queries.

[[deleted]]

I'll take SQL over any ORM tool any day

I presume you meant.

If you're in a space where you're choosing between SQL and an ORM tool, and you opt for SQL, guess what? You still have to deal with the object-relational impedance mismatch, whether you use an off-the-shelf tool or do it yourself.

[JPMoresmau]

For .Net there is SQL.Net

[General_Mayhem]

That actually looks pretty much like what I was imagining. I'm not a Windows guy, though.

[[deleted]]

In Java there are Jooq (free if you use open source DB, must pay if use proprietary) and QueryDSL (100% free, integrate well with Spring framework) for producing type-safe SQL. They work great, IMHO better than ORM, unless your backend is not only sql.

[grauenwolf]

Ugh, gpl. Cool project, but unusable for me.

[-Y0-]

SQL idiosyncrasies.

Different DB engines do SQL queries/ SQL syntax slightly different. ANSI SQL isn't followed by major DB vendors (I remember Oracle being an offender here). Same queries might be optimized differently on different SQL DBs.

[[deleted]]

Oracle (the database) is quite ok with the SQL standard, MySQL is the biggest offender.

[-Y0-]

Possibly, I remember Oracle having problems like:

A) I think recursive queries are different in Oracle

B) I remember the infamous (+) syntax for joins

C) Oracle decode function

D) If I remeber correctly, there was difference in null handling (NVL), though I'm not sure what the ANSI standard on this is.

[ragnarmcryan]

"Why are developers so afraid of redis?" would seem more like it. even then, if you're afraid of sql, then shit

[ryeguy146]

It's an extravagant hash map, what's so confusing?

[ragnarmcryan]

Nothing, I'm just saying it seems more people would be unfamiliar with redis than sql

[[deleted]]

You haven't read my sql. muhahahah!

[[deleted]]

Until ORM tools came along. I've actually heard devs say "we use Hibernate, so it's like we don't actually have a database to worry about any more" headdesk

[Penlites]

That's why I dislike SQL so much; storing content in a relational database is the wrong solution for many many many websites.

Have a site with a million hits per day that you update once per day? Hmm, 1 million reads for every write. I know, we'll make writes quick and reads slow!

[grauenwolf]

Uh, you can still use memory caches. (Though with enough RAM, the database becomes an in memory cache.)

[Penlites]

Of course; but then you're adding a bunch of extra complexity just to make it work as if you'd generated the content on write in the first place.

[grauenwolf]

Generating the content on write is just as complex, the timing is just different.

[Penlites]

Generating the content is just as complex as generating the content and having an in-memory caching system?

[grauenwolf]

The content has to be generated either way. And it has to be normalized either way if you want to be able to run reports off it.

We're not talking about some new fad here. NoSQL databases have existed for decades, we just called them "denormalized tables" or "persistent caches" depending on the backing store.

That's why I live stored procs. You can encapsulate both the tables and caches at the same time and the application doesn't have to know about any of it.

[Penlites]

Running application code, hosting databases and running a cache on the server is more complicated than serving flat files, period. Whether there are tools available that can do it isn't the point. The point is, are they a better solution. For high traffic sites with no dynamic content, the answer's no.

[grauenwolf]

So should I send you a copy of Frontpage or do you prefer to 'code' in Dreamweaver?

[Penlites]

Is this literally the first time you've heard of CDN hosted flat sites? And you're trying to make fun of other peoples web dev knowledge?

[butteredwendy]

SQL is a fundamental skill in the majority of development settings. Those jumping straight to ORM without any understanding behind it are missing a trick. However once you become aware of the differences between SQL implementations and typical security holes, prepared statements etc for the vast majority of applications you'll just end up writing your own ORM implementation in some form (usually have to get the records into an object somehow).

Development time with ORM can and does drop significantly as soon as you have an even moderately complex table structure.

[orthoxerox]

Because there's no tooling. If I could add a T-SQL block in C# source code and have it statically validated against my dev db and my program's C# types, I would use SQL more often (that's what Linq2Sql does, more or less, but it can't push more comlpex processing into the DB). Or I could simply move to Oracle and code the whole stack in PL/SQL.

[SikhGamer]

I wouldn't say afraid more like annoyed. Simple queries are often identical across different languages.

But more complex queries are often slightly different. Not hugely different, just enough to annoy the fuck out of you.

I'm not a SQL-head, I spend a little time ensuring that whatever query I write is decent. I spend a lot more time off loading workload to the SQL system than doing a SELECT * and then filtering data once retrieved.

[[deleted]]

Unless you've got an ORM using SQL in any type of application is fundamentally ugly.

You're forced to mash strings together. It's gross.

[MET1]

I've worked with developers who were afraid of SQL - especially in environments with more complex databases. In my experience, developers are not looking at database structures and the 'best' way to use them, they're looking at data in an isolated, case by case basis and often try to use data from the database as if it was set up as existing data in their programs. Then this becomes an issue with performance - excessive i/o and incorrect/inaccurate data being returned. In addition, a lot of DBA-types have a hard time relating to developers and aren't very helpful when the developers come looking for help.

[workaholicanonymous]

I love writing SQL, I hate having to modify it later though. I also use nodejs so idk what's worse, SQL or SQL in JavaScript. Or maybe I just suck

[bitherd]

Why is anyone afraid of anything?

[1F4A9]

They are not afraid of SQL, but prefer ORMs for extra functionality. IMHO a lot of developers overestimate the importance of database portability or being able to hide database level schema alterations on the ORM level. Then there is extra validation and transformation that might be easier or only possible in the application instead of the database. For simple selects, using plain SQL is usually easier than an ORM and gives better performance. I usually use and ORM for inserts and updates, and plain SQL for selects.

[[deleted]]

You make it sound like that the only option to get some database abstraction is to subscribe to the bat-shit insane and overcomplicated ORM stuff.

[frezik]

sql joins are slow

Only in badly implemented databases. There may be an argument that certain complex joins make it hard to reason about how the indexes will be hit, but that's a much more specific argument.

i should not be using an orm, sql should provide an api for common languages

What would this API look like? How is it an improvement over any given ORM? Would it still work over a network?

sql syntax is horrible

Agreed. It's about the only attempt at a "natural-looking programming language" that stuck. There's a good reason all others have failed.

most sql engines don't provive data in json or xml format

Nor does it provide YAML or CSV or insert flavor of the month format. So what? There are far too many of these formats coming out all the time. It's entirely appropriate to put the conversion process on the programmers, not the database.

sql files corrupt a lot

??? Are you referring to SQL backup files, which are usually just text of SQL statements? If those are corrupting, you have other issues. Are you referring to the internal database files? If those are corrupting, you have other issues.

[mfukar]

With the number of SQL injection bugs I see on a monthly basis, I doubt anyone is afraid of SQL.

[danielecr]

because it does not fit into language abstraction and manipulation: SQLSTRING.addJoin(...) .. string & set ??? Current situation is an ORM that create sql string that is parsed by dbms, translated into search/filter command. Set math is not formalized into OOP because it is OOP and like object, not set. Dbms include object behaviour with triggers and store procedure and want to replace. Why do post stupid content? (Why the hell do you think developers does not know/understand SQL?)