4 ms·

You can pry SQL out of my cold dead hands. Its just not that bad.

by waheoo 6y ago

Ziggy_Zaggy 6y ago
It almost seems as* SQL is a bit of a "must" by any data-heavy type of application/system so just spend 30 minutes and learn it already?
- gregjor 6y ago
  Probably more than 30 minutes, SQL may look easy but using it correctly assumes a fairly good understanding of the relational model. I agree that programmers too often seem to wave database design and integrity aside and create RDBMS/SQL worst-cases with ORMs and terrible queries, and then blame the tools.
no-s 6y ago
>>You can pry SQL out of my cold dead hands. Its just not that bad. I often joke that SQL is the COBOL of the 21st century. HHOS. There's worse things...e.g. COBOL. Actually it's very difficult to deny the empirically discernible utility of relational databases and SQL. SQLite, for example.
- waheoo 6y ago
  I'm alright with that. I think the problem is that developers love to abstract everything. And with the database often becoming a god object it's often targeted for abstraction. The problem is, querying data is a complex problem, complicated enough to require a query language. So the developer goes off to abstract the database for their needs, a helper table object here, a helper row object there and eventually you start to see an Orm appear. Developers need to be told to stop this behavior. The abstraction is the thing you are representing in the database, not the database. Your models should use plain SQL queries to execute behavior. If you must, setup some helpers to do very basic crud operations, but as soon as you need to really alter a where or a select, drop to SQL, use the language as intended and watch your code suddenly become modular, readable and maintainable. Yes, this means you will need to write SQL, yes this means you will write a lot of select and where statements, no this is not code duplication, stop freaking out about non problems. I swear to god DRY is the source of and solution to all developer problems.
- gregjor 6y ago
  COBOL and SQL are for different purposes, apples and oranges. One can’t be worse than the other. Programmers who have never seen or written COBOL should stop trotting it out as an example of bad. You’d be surprised how many important systems are written in COBOL, and how well-suited it is for the problem domains it was designed for.

You can pry SQL out of my cold dead hands. Its just not that bad.

by waheoo 6y ago

You can pry SQL out of my cold dead hands. Its just not that bad.

It almost seems as* SQL is a bit of a "must" by any data-heavy type of application/system so just spend 30 minutes and learn it already?

gregjor 6y ago
Probably more than 30 minutes, SQL may look easy but using it correctly assumes a fairly good understanding of the relational model. I agree that programmers too often seem to wave database design and integrity aside and create RDBMS/SQL worst-cases with ORMs and terrible queries, and then blame the tools.

no-s 6y ago

>>You can pry SQL out of my cold dead hands. Its just not that bad. I often joke that SQL is the COBOL of the 21st century. HHOS. There's worse things...e.g. COBOL. Actually it's very difficult to deny the empirically discernible utility of relational databases and SQL. SQLite, for example.

waheoo 6y ago
I'm alright with that. I think the problem is that developers love to abstract everything. And with the database often becoming a god object it's often targeted for abstraction. The problem is, querying data is a complex problem, complicated enough to require a query language. So the developer goes off to abstract the database for their needs, a helper table object here, a helper row object there and eventually you start to see an Orm appear. Developers need to be told to stop this behavior. The abstraction is the thing you are representing in the database, not the database. Your models should use plain SQL queries to execute behavior. If you must, setup some helpers to do very basic crud operations, but as soon as you need to really alter a where or a select, drop to SQL, use the language as intended and watch your code suddenly become modular, readable and maintainable. Yes, this means you will need to write SQL, yes this means you will write a lot of select and where statements, no this is not code duplication, stop freaking out about non problems. I swear to god DRY is the source of and solution to all developer problems.
gregjor 6y ago
COBOL and SQL are for different purposes, apples and oranges. One can’t be worse than the other. Programmers who have never seen or written COBOL should stop trotting it out as an example of bad. You’d be surprised how many important systems are written in COBOL, and how well-suited it is for the problem domains it was designed for.