We know that SQL is very similar to English, and simple SQL statements can be read directly as English. Except for SQL, other major programming lan...
For further actions, you may consider blocking this person and/or reporting abuse
SQL haters usually misunderstand what is an SQL statement and think it is like an execution instruction, with a subject and an action, like when you say:
or:
However, there is no subject, action verb or operation in SQL. It is the user specification, describing the expected result. That is why FROM is after the projection which is the declaration of the result set.
For example,
select name from airports where country='US'means: I want to see the name of the airports in US. You see that FROM is in the right place when specifying the result you want. Only when you look at the execution plan you can see how it is executed and this is not English but a tree of operations on row sets.This is also not correct:
Common Table Expressions are still declarative. For better readability they declare subqueries in WITH clause but it is the same behavior as when inlined. It is not an intermediate relational variable except if the execution plan decides to materialize it (and you can control this with optimizer hints).
It is ok to prefer coding the data access with loops, local variables, buffers, sorted or hashed stuctures, and build tests for all branching combinations, but then don't use SQL, or do simple CRUD through ORM. But SQL developers prefer to put efforts on the business logic and call a service that will find the optimal access to their data. SQL is the API for this service. Further optimisation is also declarative in SQL databases, defining indexes for you access patterns without changing the application code.
Thanks for sharing this
Thanks For sharing
You're welcome. I'm glad you like it
Respectively this feels more like a (valid) commentary on COBOL. COBOL was indeed designed to be a human-readable expression of programming constructs.
But SQL is not about programming, it is about intent, which is why the statement you make below is worth challenging:
The true advantage of natural language lies in its ambiguity, which allows it to accept less strict syntax to a certain extent
I would contend the true advantage is that natural language allows it to be self-evident was the goal of the task is. Show someone an SQL, and even if they have no idea how the result would be computed, they'll have a good chance of knowing what the intention is.
Don't get me wrong, SQL is not by means utopia for that, but present a novice (developer or otherwise) with a SQL statement to get average salaries by department versus the equivalent in C++, and I'll wager they can digest the SQL version far more quickly.