Porque é que a gramática de dentro para fora do SQL?

Question

Em praticamente qualquer conjunto formalmente estruturado de informações, você começar a ler a partir do início para o final, ou, ocasionalmente, a partir do final para o começo (endereços de rua, por exemplo.) Mas, em SQL, SELECIONE especialmente consultas, a fim para compreender corretamente o seu significado você tem que começar no meio, na cláusula FROM. Isso pode fazer consultas de longa muito difícil de ler, especialmente se contiver consultas SELECT aninhadas.

Normalmente, na programação, quando algo não parece fazer qualquer sentido, há uma razão histórica por trás dele. Começando com o SELECT em vez da DA não faz sentido. Alguém sabe a razão que é feito dessa maneira?

Answer 1

O SQL Wikipedia entrada descreve brevemente um pouco de história:

Durante os anos 1970, um grupo na IBM San Jose Research Laboratory desenvolveu o sistema de gerenciamento de banco de dados relacional sistema R, com base no modelo introduzido por Edgar F. Codd em seu papel influente, "um modelo relacional de dados para Large Shared dados Banks ". Donald D. Chamberlin e Raymond F. Boyce da IBM, posteriormente, criou o Inglês Estruturado Query Language (SEQUEL) para manipular e gerenciar dados armazenados no Sistema R. O acrônimo SEQUEL foi posteriormente alterado para SQL porque "sequência" era uma marca da empresa de aeronaves Hawker Siddeley sediada no Reino Unido.

O nome original mencionado explicitamente Inglês , explicando a sintaxe.

Indo um pouco mais fundo, encontramos a href="http://en.wikipedia.org/wiki/FLOW-MATIC" rel="nofollow noreferrer"> FLOW-MATIC linguagem de programação

FLOW-MATIC, originalmente conhecida como B-0 (Business Language versão 0), é, possivelmente, a primeira língua-like Inglês processamento de dados . Foi inventado e especificados por Grace Hopper, eo desenvolvimento da variante comercial começou no Remington Rand em 1955 para o UNIVAC I. Em 1958, o compilador e sua documentação foram geralmente disponível e sendo usado comercialmente.

FLOW-MATIC foi a inspiração por trás da Common Business Oriented Language , um das línguas mais antigas programação ainda em uso ativo. Mantendo-se com esse espírito, SEQUEL foi projetado com Inglês-como sintaxe (1970 é moderna, em comparação com 1950 e 1960).

Em perspectiva, os sistemas "modernos" de programação ainda bases de dados Access usando as ideias de velhice por trás

MULTIPLY PRICE BY QUANTITY GIVING COST.

Answer 2

Eu acho que a maneira em que uma instrução SQL é estruturado faz sentido lógico, tanto quanto frases em inglês são estruturados. Basicamente

I WANT THIS
FROM HERE
WHERE WHAT I WANT MEETS THESE CRITERIA

Eu não acho que faz muito sentido, em Inglês, pelo menos, para dizer

FROM HERE
I WANT THIS
WHERE WHAT I WANT MEETS THESE CRITERIA  

Answer 3

Eu devo discordar. gramática SQL não é de dentro para fora.

do primeiro olhar você pode dizer se a consulta SELECT, INSERT, UPDATE ou dados delete (todo o resto do SQL, por exemplo DDL, omitiu de propósito).

---

Voltar para sua confusão instrução SELECT: O objetivo do SQL é ser declarativa . Que significa que você expressar o que você quer e não como você quer. Por isso, faz todo o sentido para início estado que você quer (lista de atributos que você está selecione ing) e então fornecer os DBMS com algum adicional informações sobre onde que deve ser olhou para cima de.

A colocação da cláusula WHERE no final faz grande sentido também: Imagine um funil, largura na parte superior, estreitar na parte inferior. Ao adicionar uma cláusula WHERE para o fim da instrução, você está sufocando para baixo a quantidade de dados resultantes. Aplicar restrições à sua consulta em qualquer outro lugar do que no fundo exigiria o desenvolvedor para virar a cabeça ao redor.

---

cláusula ORDER BY no final:., Uma vez que os dados tenham ido através do funil, classificá-lo

junta (Cadastre critérios) realmente pertencem na cláusula FROM.

agrupamento:. De dados, basicamente, em execução através de um funil antes que ele chegue em outro funil

sytax

SQL é doce. Não há nada dentro para fora sobre ele. Talvez por isso SQL é tão popular mesmo depois de tantas décadas. É bastante fácil de entender e de fazer sentido fora. (Embora eu tenha uma vez enfrentou um de 7 páginas (tamanho A4) instrução SQL que me levou muito tempo para ter a minha cabeça ao redor.)

Answer 4

Ele foi projetado para ser o Inglês como. Eu acho que é a principal razão.

Como uma nota lateral, eu me lembro as visualizações iniciais de LINQ foram modelados diretamente após ele (select ... from ...). Isto foi mudado em previews posteriores a ser mais linguagem de programação como (de modo que o escopo vai para baixo). Anders Hejlsberg especificamente mencionado esse fato estranho sobre SQL (que faz IntelliSense mais difícil e não corresponde C regras # escopo) como a razão pela qual eles tomaram essa decisão.

De qualquer forma, bom ou mau, é o que é e que seja tarde demais para mudar qualquer coisa.

Answer 5

A ordem das cláusulas SQL é absolutamente lógico. Lembre-se que SQL é uma linguagem declarativa, onde você declarar que você quer e o sistema calcula a melhor forma de obtê-lo para você. A primeira cláusula é a cláusula select onde você lista as colunas que deseja na tabela de resultados. Este é o objetivo principal da consulta. Tendo afirmado que você quer o resultado para se parecer, você próximo estado onde os dados devem vir. A cláusula onde limita a quantidade de dados a ser devolvida. Não há nenhum ponto em pensar sobre como limitar os seus dados se você não sabe de onde vem, assim vai após a cláusula FROM. O grupo pela cláusula trabalha com os operadores de agregação na cláusula SELECT e poderia ir a qualquer lugar após a cláusula FROM no entanto, é melhor pensar sobre a agregação dos dados filtrados, por isso vem depois de a cláusula onde. A cláusula having tem que vir depois que o grupo pela cláusula. A cláusula ORDER BY é sobre como os dados são apresentados e podem ir a qualquer lugar após a seleção.

Answer 6

É coerente com o resto da sintaxe de ter cada início de declaração com um verbo (CREATE, DROP, UPDATE, etc.) Do SQL.

A principal desvantagem de ter a lista de colunas primeira é que inconveniente é para auto-complete (como Hejlsberg mencionou), mas isso não foi uma preocupação quando a sintaxe foi projetado na década de 1970.

Nós poderíamos ter tido o melhor dos dois mundos com uma sintaxe como SELECT FROM SomeTable: ColumnA, ColumnB, mas é tarde demais para mudar isso agora.

De qualquer forma, a ordem declaração SELECT do SQL não é única. Ele corresponde exatamente a de Python lista compreensões:

[(rec.a, rec.b) for rec in data where rec.a > 0]

Answer 7

História da língua de lado (embora seja fascinante) Acho que a coisa que está faltando é que o SQL não é sobre dizendo ao sistema o que fazer, tanto quanto o resultado final que você quer (e descobre como fazê-lo)

dizendo 'vá até lá para que rack, pegar os chapéus com hatbands, chapéus azuis primeiro, depois verde, depois vermelho, e trazê-los para mim' é muito dizendo ao sistema como para faça o que você quiser. -lo do programador pense , onde supomos que o trabalhador é muito estúpido e precisa de instruções minuciosas.

SQL está começando com o resultado final em primeiro lugar, os dados que deseja, a ordem das colunas, etc .. é muito da perspectiva de alguém que está construindo um relatório. "Quero nome, sobrenome, então idade, então ....." Isso é, afinal, o propósito de fazer o pedido. Então ele começa com isso, o formato dos resultados que você deseja. Em seguida, ele vai para onde você espera que ele encontrar os dados, quais os critérios que procurar, a fim de apresentá-la, etc.

Assim como uma alternativa para especificando em pormenor o que você quer o trabalhador a fazer, SQL presume o sistema sabe como fazer isso, e os centros mais do que você quer.

Assim, em vez de dizer pedantically seu trabalhador para ir aqui, veja só, trazê-lo de lá .. é mais como dizer "eu quero chapéus, de cremalheira 12, que tem hatbands e agradar tipo-los por cor."