74

This is something that bothered me a lot at school.

Five years ago, when I learned SQL, I always wondered why we first specify the fields we want and then where we want them from.

According to my idea, we should write:

From Employee e
Select e.Name

So why does the norm say the following?

Select e.Name -- Eeeeek, what does e mean?
From Employee e -- Ok, now I know what e is

It took me weeks to understand SQL, and I know that a lot of that time was consumed by the wrong order of elements.

It is like writing in C#:

string name = employee.Name;
var employee = this.GetEmployee();

So, I assume that it has a historical reason. Why?

Peter Mortensen
  • 1,045
Cyril Gandon
  • 1,346

6 Answers6

91

Originally SQL language was called SEQUEL standing for

  • Structured English Query Language
    with the emphasize on English, assuming it to be close in spelling to natural language.

Now, spell these two statements as you'd spell English sentences:

  1. "From Employee table e Select column e.Name"
  2. "Select column e.Name From Employee table e"

Second sounds closer to natural English language that's why it is set as norm.

BTW same reasoning goes to Where etc - SQL statements were intentionally designed to sound close to natural language.

gnat
  • 20,543
  • 29
  • 115
  • 306
37

Because SELECT is required in a select statement and FROM is not.

Select 'This String'

Of course your sql statement can be parsed to look for the SELECT, DELETE, UPDATE after the FROM, but is is really that big of a deal?

Remember, this was all done before intellisense. It's not that complicated.

Edit: There's probably no reason sql interpreters couldn't be built to do both.

JeffO
  • 36,956
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.

0x4B1D
  • 241
5

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.

BillThor
  • 6,310
3

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.

David Cloutman
  • 109
2

I think it would significantly complicate parsing, especially with subqueries, e.g.

  FROM Foo f
  JOIN (FROM Bar b
        WHERE b.ID = f.ID
        UPDATE b
           SET b.Wibble = 1) x
    ON x.ID = f.ID
SELECT f.XYZ

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.

ConcernedOfTunbridgeWells
  • 161
  • 5