Por que o Select antes do De em uma consulta SQL? [fechadas]

Originalmente, a linguagem SQL era chamada de SEQUEL representando

• Linguagem de consulta Inglês estruturada com ênfase em inglês , supondo que seja próximo da ortografia da linguagem natural .

Agora, soletre essas duas declarações ao escrever frases em inglês:

1. "Da tabela Employee e Selecione a coluna e.Name"
2. "Selecione a coluna e.Name da tabela Employee e"

O segundo parece mais próximo da língua natural inglesa, por isso é definido como norma.

O mesmo raciocínio BTW vai para Where etc - instruções SQL foram intencionalmente projetadas para parecer próximas à linguagem natural.

Porque SELECT é necessário em uma instrução select e FROM não é.

Select 'This String'

É claro que sua instrução sql pode ser analisada para procurar SELECT, DELETE, UPDATE após o FROM, mas é realmente um grande negócio?

Lembre-se, tudo isso foi feito antes do intellisense. Não é tão complicado assim.

Edit: Provavelmente não há razão para que intérpretes sql não possam ser construídos para fazer ambos.

Não sei uma resposta que eu poderia fazer por referências, mas se eu tivesse que especular: SQL é uma linguagem declarativa , uma declaração de tal linguagem descreve o que você gostaria de fazer em oposição a como você gostaria de fazê-lo.

Assim, "SELECT X FROM Y" soa como uma maneira mais apropriada de responder "O que eu gostaria de selecionar no banco de dados", em vez de escrever "FROM Y SELECT X".

Além disso, no SQL, o SELECT / UPDATE / INSERT especifica o tipo de operação que você está prestes a fazer e FROM é apenas uma cláusula que ajuda a selecionar a tabela correta no banco de dados. Novamente, o que você está fazendo com dados tem precedência sobre como exatamente você vai conseguir isso.

SQL é uma linguagem de consulta estruturada voltada para falantes de inglês. SELECT, INSERT, UPDATE e DELETE são comandos imperativos. Em inglês, comandos imperativos iniciam a sentença ou declaração. Comparar:

West young man go!

para

Go west young man!

O SQL segue o segundo formato (imperativo). Além disso, os quatro comandos imperativos possuem três formatos significativamente diferentes. Considere:

FROM    employees a,
        accounts b
UPDATE  ...

ou

INTO    customers a
SELECT  ...

Se você souber a ação que está realizando, será mais fácil selecionar o formato correto.

No caso de selecionar, você determina quais atributos deseja e, em seguida, adiciona as tabelas que os possuem. Ao criar os critérios de seleção, você pode adicionar tabelas adicionais. Quando você está adicionando critérios dinamicamente, isso geralmente pode ser feito no final de uma parte estática da consulta.

As instruções SQL começam com verbos. Essa foi a escolha dos designers de linguagem e muitas linguagens de programação funcionam dessa maneira. Semanticamente, não é incomum ver linguagens de programação que funcionam assim:

verb(noun, noun, noun);

Além disso, no caso da instrução SELECT fornecida como exemplo, a sintaxe proposta colocaria o objeto primeiro na instrução. Em vez de uma ordem de sentença VSO (verbo, sujeito, objeto), você teria OVS, o que seria muito estranho quando comparado às linguagens naturais. SVO (por exemplo, inglês), VSO (por exemplo, árabe) e SOV (por exemplo, latim) são aproximações mais razoáveis da fala humana.

Acho que isso complicaria significativamente a análise, especialmente com subconsultas, por exemplo,

  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

Analisar isso seria mais complicado. Você não poderia dizer que o UPDATE era um erro de sintaxe até você ter analisado a cláusula FROM, e o analisador teria que lembrar de um contexto suficiente para saber que estava analisando uma subconsulta. Eu não acho que as atualizações são permitidas em subconsultas de qualquer maneira, mas se elas fossem (talvez com uma cláusula RETURNING), então você pode não ser capaz de dizer que isso é inválido até você ter analisado a instrução SELECT.

Isso aumentaria, pelo menos, k (lookahead) para a gramática e, na pior das hipóteses, tornaria o contexto sensível, embora isso estenda os limites dos meus trabalhos de design de compilador da universidade.