Why are developers so afraid of SQL?
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
Kent Sharkey wrote:
Why are developers so afraid of SQL?
I am afraid of it because it's a three letter acronym and I have a fear of all TLAs. :omg:
You can lead a developer to CodeProject, but you can't make them think. The Theory of Gravity was invented for the sole purpose of distracting you from investigating the scientific fact that the Earth sucks.
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
Never knew developers are afraid of SQL - sounds me all wrong. In my schedule at college SQL was there every week...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
To me the author of this text simply doesn't understand why people don't like SQL. He even talks about ORMs, but he missed the point entirely. Many developers don't have a problem with SQL. They don't have a problem with the programming language either. Their problem is the mismatch between SQL and the language they need to use and the amount of duplicated code. Without an ORM, the developer is going to write the SQL, then either use a DataTable (pretty bad) or a DataReader. If the developer uses a data-reader to populate an object (I worked in many places that do this), the developer needs to write the sql + write the code that reads every database field to populate an object. Also, any error when writing the field names will only be found while executing the code. In this sense, it is natural to avoid writing one of them if you can. And honestly, joins are stupid too. Most joins are based on foreign key fields, and there's only one possible join from one table to the other, yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable" without having to specify the joining fields all the time, reserving it for exceptional cases.
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
-
To me the author of this text simply doesn't understand why people don't like SQL. He even talks about ORMs, but he missed the point entirely. Many developers don't have a problem with SQL. They don't have a problem with the programming language either. Their problem is the mismatch between SQL and the language they need to use and the amount of duplicated code. Without an ORM, the developer is going to write the SQL, then either use a DataTable (pretty bad) or a DataReader. If the developer uses a data-reader to populate an object (I worked in many places that do this), the developer needs to write the sql + write the code that reads every database field to populate an object. Also, any error when writing the field names will only be found while executing the code. In this sense, it is natural to avoid writing one of them if you can. And honestly, joins are stupid too. Most joins are based on foreign key fields, and there's only one possible join from one table to the other, yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable" without having to specify the joining fields all the time, reserving it for exceptional cases.
Paulo Zemek wrote:
Without an ORM, the developer is going to write the SQL,
...
Paulo Zemek wrote:
yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable"
... Ugh. Anyone that is still writing SQL directly in their code should be shot. I'm definitely not an advocate of ORM's, but it doesn't take very much effort to put together a decent enough SQL generator that covers 90% or more of the use cases, based simply on the schema. Oh wait, I forgot. A lot of the databases I've seen don't actually have usable schemas defining FK relationships, unique keys, even primary keys that are non-data fields. :rolleyes: Marc
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
Fear of SQL is a sign of weakness.
-
Fear of SQL is a sign of weakness.
That sounds almost like a Dune koan
TTFN - Kent
-
That sounds almost like a Dune koan
TTFN - Kent
Hadn't thought of that.
-
Paulo Zemek wrote:
Without an ORM, the developer is going to write the SQL,
...
Paulo Zemek wrote:
yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable"
... Ugh. Anyone that is still writing SQL directly in their code should be shot. I'm definitely not an advocate of ORM's, but it doesn't take very much effort to put together a decent enough SQL generator that covers 90% or more of the use cases, based simply on the schema. Oh wait, I forgot. A lot of the databases I've seen don't actually have usable schemas defining FK relationships, unique keys, even primary keys that are non-data fields. :rolleyes: Marc
We use a lot of SQL - of course, but there is no a single line of it in the code. When I want some data I load an entity (not of .NET but using a 2 decade old idea of our own) identifying it by it's name and passing it some parameters. The entity itself was created by a home-made ORM like tool and saved in the database itself...No SQL whatsoever in code!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Time and again, I run into developers who**'''**s feeling towards SQL ranges from slight discomfort to shear terror
SQL injection - the most terrifying injection of my adult life :-)
Of course, it wouldn't be a problem if the author had used the correct word! :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Paulo Zemek wrote:
Without an ORM, the developer is going to write the SQL,
...
Paulo Zemek wrote:
yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable"
... Ugh. Anyone that is still writing SQL directly in their code should be shot. I'm definitely not an advocate of ORM's, but it doesn't take very much effort to put together a decent enough SQL generator that covers 90% or more of the use cases, based simply on the schema. Oh wait, I forgot. A lot of the databases I've seen don't actually have usable schemas defining FK relationships, unique keys, even primary keys that are non-data fields. :rolleyes: Marc
Being afraid of SQL is a strange exaggeration in my opinion. The only wierd SQL stuff is all the inner and outer etc. joins. They are hard to understand. I feel better working with smaller blocks of code one selection at a time and the narrowing in of the data set. Linq helps us doing that. And after all developers loves Linq mostly.
Michael Pauli
-
Unconnected[^]:
Time and again, I run into developers who's feeling towards SQL ranges from slight discomfort to shear terror.
It's all that SELECTing and JOINing: it reminds us of being picked last for team sports at school
-
Paulo Zemek wrote:
Without an ORM, the developer is going to write the SQL,
...
Paulo Zemek wrote:
yet developers must repeat all the fields in the "ON" clause. It would be much nicer if SQL allowed us to say "INNER JOIN otherTable"
... Ugh. Anyone that is still writing SQL directly in their code should be shot. I'm definitely not an advocate of ORM's, but it doesn't take very much effort to put together a decent enough SQL generator that covers 90% or more of the use cases, based simply on the schema. Oh wait, I forgot. A lot of the databases I've seen don't actually have usable schemas defining FK relationships, unique keys, even primary keys that are non-data fields. :rolleyes: Marc
