4 ms·

In regards to 'select' before 'from', there could be a similar argument to be made for declaring imports at the top of a file. When you write a program, you may

In regards to 'select' before 'from', there could be a similar argument to be made for declaring imports at the top of a file. When you write a program, you may not know what libraries you need. Variable declaration at the beginning of a function is also a common pattern. The SQL language stood the test of time where as COBOL did not. I think it says something about how well it was designed. I strongly suspect that developers have such a hard time with it is because of ORM. ORM trains you to think of the database as objects. Another poster mentioned that treating databases like sets made SQL click. I think that is a good way of thinking about SQL. To be fair, SQL does have some archaic things in there that make it annoying to work with. However, once it clicks, it's fits naturally with how a relational db works.

setr 7y ago
>Variable declaration at the beginning of a function is also a common pattern What language requires you to declare variables at the beginning? C even stopped doing that. People choose to do that, but ime that's after the writing phase, to make it more readable >When you write a program, you may not know what libraries you need Sort of -- the difference is that when I'm writing code in my IDE, I know all database objects available to me. It's in the schema. A library I import once (to the project itself), and the IDE can always assist from then-on. But SQL is designed such that despite the library (schema) being imported, the IDE can't actually assist, unless I write the code out of order (eg start with SELECT * FROM table and then start working) >However, once it clicks, it's fits naturally with how a relational db works I think you've misunderstood the complaint -- the relational language is a very strong concept, which has stood the test of time, and is difficult to complain about -- it does its job well, and fits naturally with how a relational db works. SQL the language however is: A hodgepodge of random keywords tossed about in a totally inconsistent fashion (eg postgres overlay: OVERLAY('Txxxxas' PLACING 'hom' FROM 2 FOR 4) -- postgres at least generally offers a consistent comma-separated syntax for every functions has weird and technically unnecessary limitations (like SELECT being evaluated after the WHERE clause, so you can't use the aliases defined in select clause) putting SELECT before the FROM (disabling IDE auto-complete support) the stuffing of a 3-value logic system into a 2-value logic interface, so boolean operations break silently and produce nonsense in the face of a database with NULL values, because no mapping of NOT (TRUE, FALSE, NULL) AND NULL makes sense. [0] It generally composes very poorly, leading to redundant, long and convoluted queries The MODEL is fantastic -- the language is not. [0] https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs/03_principles_Guagliardo.pdf https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs...

setr 7y ago

>Variable declaration at the beginning of a function is also a common pattern What language requires you to declare variables at the beginning? C even stopped doing that. People choose to do that, but ime that's after the writing phase, to make it more readable >When you write a program, you may not know what libraries you need Sort of -- the difference is that when I'm writing code in my IDE, I know all database objects available to me. It's in the schema. A library I import once (to the project itself), and the IDE can always assist from then-on. But SQL is designed such that despite the library (schema) being imported, the IDE can't actually assist, unless I write the code out of order (eg start with SELECT * FROM table and then start working) >However, once it clicks, it's fits naturally with how a relational db works I think you've misunderstood the complaint -- the relational language is a very strong concept, which has stood the test of time, and is difficult to complain about -- it does its job well, and fits naturally with how a relational db works. SQL the language however is: A hodgepodge of random keywords tossed about in a totally inconsistent fashion (eg postgres overlay: OVERLAY('Txxxxas' PLACING 'hom' FROM 2 FOR 4) -- postgres at least generally offers a consistent comma-separated syntax for every functions has weird and technically unnecessary limitations (like SELECT being evaluated after the WHERE clause, so you can't use the aliases defined in select clause) putting SELECT before the FROM (disabling IDE auto-complete support) the stuffing of a 3-value logic system into a 2-value logic interface, so boolean operations break silently and produce nonsense in the face of a database with NULL values, because no mapping of NOT (TRUE, FALSE, NULL) AND NULL makes sense. [0] It generally composes very poorly, leading to redundant, long and convoluted queries The MODEL is fantastic -- the language is not. [0] https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs/03_principles_Guagliardo.pdf https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs...