As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

Unfortunately, I can't find any relevant info in the paper that introduced SEQUEL, and I don't think there are specific citations that answer your question. gnat's answer is possibly the best explanation though - but I wouldn't dismiss the conspiracy theory.
–
Yannis♦Dec 30 '11 at 14:07

2

Personally, I've always wished Linq could not have used the standardized SQL syntax.
–
jp2codeDec 30 '11 at 15:53

3

The clauses in a SELECT statement are not the order of the operation.
–
S.LottDec 30 '11 at 17:06

8

Nice question. You're next one should be why INSERT and UPDATE queries had to use different syntax models: (field1, field2) VALUES (f1, f2) vs (field1=f1, field2=f2).
–
LarsTechDec 30 '11 at 18:10

Do not know an answer that I could back up by references, but if I had to speculate: SQL is a declarative language, a statement of such language describes what you would like to do as opposed to how you would like to do it.

As such, "SELECT X FROM Y" sounds as a more appropriate way of answering "What would I like to select from the database", as opposed to writing "FROM Y SELECT X".

In addition, in SQL, the SELECT/UPDATE/INSERT specifies the type of operation you are about to do and FROM is just a clause that helps you select from the right table in the database. Again, what are you doing with data takes precedence over how exactly you are going to achieve that.

SQL is a structured query language targeted to English speakers. SELECT, INSERT, UPDATE, and DELETE are imperative commands. In English imperative commands begin the sentence or statement. Compare:

West young man go!

to

Go west young man!

SQL follows the second (imperative) format. Also the four imperative commands have three significantly different formats. Consider:

FROM employees a,
accounts b
UPDATE ...

or

INTO customers a
SELECT ...

If you know the action you are undertaking, it is easier to select the correct format.

In the case of select, you determine which attributes you want, then add the tables that have them. As you build the selection criteria, you may add additional tables. When you are dynamically adding criteria, it can usually be done at the end of a static portion of the query.

Parsing this would be more complicated. You could not tell that the UPDATE was a syntax error until you had parsed the FROM clause, and the parser would have to remember enough context to know that it was parsing a subquery. I don't think updates are permissible in subqueries anyway, but if they were (maybe with a RETURNING clause) then you might not be able to tell this was invalid until you had parsed the SELECT statement.

This would at least increase k (lookahead) for the grammar and at worst make it context sensitive, although this is stretching the bounds of my rather dimly remembered compiler design papers from university.

SQL statements begin with verbs. That was the choice of the language designers, and many programming languages work that way. Semantically, it is not uncommon to see programming languages that work like this:

verb(noun, noun, noun);

Also, in the case of SELECT statement that you give as an example, your proposed syntax would put the object first in the statement. Instead of a VSO (verb, subject, object) sentence order, you would have OVS, which would be a very strange when compared to natural languages. SVO (e.g. English), VSO (e.g. Arabic), and SOV (e.g. Latin) are more reasonable approximations of human speech.