4 ms·

lately I discovered that many developers don't know SQL and didn't attend to any DB course at university My DB course taught us relational algebra and calculus

by gaius 8y ago

lately I discovered that many developers don't know SQL and didn't attend to any DB course at university My DB course taught us relational algebra and calculus and you were expected to learn SQL independently. I am constantly bemused tho’ at the extraordinary lengths some devs will go to to avoid SQL. I’ve known people who will grudgingly do SELECT * FROM table; then extract the one row/column they want on the client. Then they complain that the DB is slow when it’s loadavg is 0.01...

weberc2 8y ago
To be fair, SQL isn't exactly a friendly language. It's basically relational algebra and a grab bag of utilities for dealing with whatever technology was in-vogue at each iteration of the standard. Relational algebra + xml + json + etc. And even in spite of all of the extra tacked-on features, you can't push standard SQL very far before you need to depend on implementation-specific features. So yeah, everyone should learn SQL, but I can appreciate the reluctance to dive in.
- theandrewbailey 8y ago
  I find SQL queries (select, insert, delete...) to be fairly friendly. It's kind of like semi-broken English where you fill in the blanks. My first programming language was Python, and SQL queries weren't a big deal, once I knew how to order the clauses. Though, once you get into more advanced things like stored procedures and triggers, SQL becomes a little hostile.
- jmulho 8y ago
  It is like the developer's mind is somehow incompatible with SQL. SQL = relational algebra + xml + json? That is most certainly not going to be friendly. Xml and json are for NoSQL. Keep it that way and you will eventually see the light.
  - weberc2 8y ago
    I'm not sure what your point is, but you may have missed mine. My point is that SQL has had a lot of things bolted onto its relational algebra roots. XML and JSON were two examples, but stored procedures, triggers, window functions, are others and the list is quite long (and growing!). The problem isn't so much that SQL can do a lot, but that there's no wholistic theory belying it all; it's all just bolted on. And you can't just stick to the relational algebra subset of SQL because that won't get you very far; the features that were bolted on solve real problems, but ideally we'll find a more powerful theory than relational algebra that will do a better job at wholistically solving the set of problems we're trying to make SQL solve.
    - jmulho 8y ago
      There is a theory underlying it all: relational algebra, as you mentioned. The bolted on parts are just that. My point is discard those (XML and JSON in particular) and SQL is not at all unfriendly. It is in fact the friendliest way yet discovered to deal with data in large shared data banks. XML and JSON (as a model for how to store large amounts of data) are an absolute disaster by comparison. XML and JSON features exist in databases primarily to check a box on sales presentations. They aren't needed. If you are using them heavily, you are making your life more difficult than it needs to be. XML and JSON database features aren't completely useless. They are one of many tools you can use to get data out of XML and JSON and put it into normalized tables where it can be efficiently and elegantly stored, accessed, and otherwise dealt with in the future. The relational algebra subset of SQL (tables, rows, columns, primary keys, referential integrity constraints, check constraints, indexes, joins, where clauses, etc.) will get you very, very far. My second point is that something about relational databases and SQL just doesn't sit well with (many) software developers. As a result, we have a lot of XML and JSON blobs stored in key/value databases, a lot of software that doesn't work very well, and we are still dealing with a lot of problems that Ted Codd solved 48 years ago.
      - weberc2 8y ago
        I followed your point, but my point is that the relational algebra part of SQL isn’t sufficient to solve all or most of our info search/retrieval problems; you end up needing other things—analytics, window functions, polymorphism, etc. You can’t push vanilla relational algebra SQL very far before you need some extension.
Uberphallus 8y ago
Funnily, and contrary to the article, in my previous job QAs did SQL to validate the operation of the app, and usually better than the devs themselves.

by gaius 8y ago

weberc2 8y ago

To be fair, SQL isn't exactly a friendly language. It's basically relational algebra and a grab bag of utilities for dealing with whatever technology was in-vogue at each iteration of the standard. Relational algebra + xml + json + etc. And even in spite of all of the extra tacked-on features, you can't push standard SQL very far before you need to depend on implementation-specific features. So yeah, everyone should learn SQL, but I can appreciate the reluctance to dive in.

theandrewbailey 8y ago
I find SQL queries (select, insert, delete...) to be fairly friendly. It's kind of like semi-broken English where you fill in the blanks. My first programming language was Python, and SQL queries weren't a big deal, once I knew how to order the clauses. Though, once you get into more advanced things like stored procedures and triggers, SQL becomes a little hostile.
jmulho 8y ago
It is like the developer's mind is somehow incompatible with SQL. SQL = relational algebra + xml + json? That is most certainly not going to be friendly. Xml and json are for NoSQL. Keep it that way and you will eventually see the light.
- weberc2 8y ago
  I'm not sure what your point is, but you may have missed mine. My point is that SQL has had a lot of things bolted onto its relational algebra roots. XML and JSON were two examples, but stored procedures, triggers, window functions, are others and the list is quite long (and growing!). The problem isn't so much that SQL can do a lot, but that there's no wholistic theory belying it all; it's all just bolted on. And you can't just stick to the relational algebra subset of SQL because that won't get you very far; the features that were bolted on solve real problems, but ideally we'll find a more powerful theory than relational algebra that will do a better job at wholistically solving the set of problems we're trying to make SQL solve.
  - jmulho 8y ago
    There is a theory underlying it all: relational algebra, as you mentioned. The bolted on parts are just that. My point is discard those (XML and JSON in particular) and SQL is not at all unfriendly. It is in fact the friendliest way yet discovered to deal with data in large shared data banks. XML and JSON (as a model for how to store large amounts of data) are an absolute disaster by comparison. XML and JSON features exist in databases primarily to check a box on sales presentations. They aren't needed. If you are using them heavily, you are making your life more difficult than it needs to be. XML and JSON database features aren't completely useless. They are one of many tools you can use to get data out of XML and JSON and put it into normalized tables where it can be efficiently and elegantly stored, accessed, and otherwise dealt with in the future. The relational algebra subset of SQL (tables, rows, columns, primary keys, referential integrity constraints, check constraints, indexes, joins, where clauses, etc.) will get you very, very far. My second point is that something about relational databases and SQL just doesn't sit well with (many) software developers. As a result, we have a lot of XML and JSON blobs stored in key/value databases, a lot of software that doesn't work very well, and we are still dealing with a lot of problems that Ted Codd solved 48 years ago.
    - weberc2 8y ago
      I followed your point, but my point is that the relational algebra part of SQL isn’t sufficient to solve all or most of our info search/retrieval problems; you end up needing other things—analytics, window functions, polymorphism, etc. You can’t push vanilla relational algebra SQL very far before you need some extension.

Uberphallus 8y ago

Funnily, and contrary to the article, in my previous job QAs did SQL to validate the operation of the app, and usually better than the devs themselves.