Return to Answer

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the use-case example sentences they translate into SQL:

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

Q3: Find the items sold by departments on the second floor.

Q4: Find the average salary of employees in the shoe department.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> <satisfying some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

So the order of clauses follows naturally from the desire to have the language be English-like.

The controversial question is if it was a good idea striving for an English-like language. In my experience it makes it far more accessible for non-programmers, but makes it rather clunky for programmers. (Note that Linq have reversed the two first clauses to better support autocompletion. Obviously autocompletion did not exist at the time SQL was designed. Linq also supports composition much more elegantly. Then again Linq is not designed for use by non-programmers.)

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the use-case example sentences they translate into SQL:

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

Q3: Find the items sold by departments on the second floor.

Q4: Find the average salary of employees in the shoe department.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> <satisfying some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

So the order of clauses follows naturally from the desire to have the language be English-like.

The controversial question is if it was a good idea striving for an English-like language. In my experience it makes it far more accessible for non-programmers, but makes it rather clunky for programmers. (Note that Linq have reversed the two first clauses to better support autocompletion. Obviously autocompletion did not exist at the time SQL was designed. Linq also supports composition much more elegantly. Then again Linq is not designed for use by non-programmers.)

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the example sentences they translate into SQL.

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

Q3: Find the items sold by departments on the second floor.

Q4: Find the average salary of employees in the shoe department.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> <satisfying some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

So the order of clauses follows naturally from the desire to have the language be English-like. The controversial question is if it was a good idea striving for an English-like language. In my experience it makes it far more accessible for non-programmers, but makes it rather clunky for programmers. (Note that Linq have reversed to first clauses to better support autocompletion. Obviously autocompletion did not exist at the time SQL was designed. Linq also supports composition much more elegantly.)

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the use-case example sentences they translate into SQL:

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

Q3: Find the items sold by departments on the second floor.

Q4: Find the average salary of employees in the shoe department.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> <satisfying some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

So the order of clauses follows naturally from the desire to have the language be English-like. 

The controversial question is if it was a good idea striving for an English-like language. In my experience it makes it far more accessible for non-programmers, but makes it rather clunky for programmers. (Note that Linq have reversed the two first clauses to better support autocompletion. Obviously autocompletion did not exist at the time SQL was designed. Linq also supports composition much more elegantly. Then again Linq is not designed for use by non-programmers.)

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the example sentences they translate into SQL.

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> where <some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

SQL was designed to be English-like, which means the expressions should more or less read like English sentences. In the initial paper you can see the example sentences they translate into SQL.

Q1. Find the names of employees in the toy department.

Q2: Find the names and salaries of employees who are in the toy department and whose manager is Anderson.

Q3: Find the items sold by departments on the second floor.

Q4: Find the average salary of employees in the shoe department.

etc.

You will notice these sentences naturally follow this template:

Find <property> of <entity> <satisfying some condition> 

Which leads to the SQL syntax:

SELECT <columns> FROM <table> WHERE <predicate> 

So the order of clauses follows naturally from the desire to have the language be English-like. The controversial question is if it was a good idea striving for an English-like language. In my experience it makes it far more accessible for non-programmers, but makes it rather clunky for programmers. (Note that Linq have reversed to first clauses to better support autocompletion. Obviously autocompletion did not exist at the time SQL was designed. Linq also supports composition much more elegantly.)