Pourquoi la grammaire de SQL inside-out?

Question

Dans à peu près tout ensemble d'informations, vous commencez à lire soit depuis le début à la fin, ou à l'occasion de la fin formellement structuré vers le début (adresses de la rue, par exemple.) Mais dans SQL, en particulier les requêtes SELECT, afin de bien comprendre le sens que vous devez commencer au milieu, à la clause FROM. Cela peut faire de longues requêtes très difficiles à lire, surtout si elle contient des requêtes imbriquées SELECT.

En général, dans la programmation, quand quelque chose ne semble pas avoir de sens, il y a une raison historique derrière elle. En commençant par le SELECT au lieu de FROM n'a pas de sens. Est-ce que quelqu'un sait la raison pour laquelle il est fait de cette façon?

Answer 1

L'entrée SQL Wikipédia décrit brièvement un peu d'histoire:

  

Au cours des années 1970, un groupe au laboratoire de recherche IBM San Jose a développé le système de gestion de base de données relationnelle système R, basée sur le modèle mis en place par Edgar F. Codd dans son journal influent, « un modèle relationnel de données pour les grandes banques de données partagées ». Donald D. Chamberlin et Raymond F. Boyce d'IBM par la suite créé le Structured Query Language anglais (SEQUEL) pour manipuler et gérer les données stockées dans R. système Sequel acronyme a ensuite été changé en SQL parce que "sequel" était une marque de la société Hawker Siddeley britannique.

Le nom original explicitement mentionné anglais , expliquant la syntaxe.

Creuser un peu plus, nous trouvons le FLOW-MATIC langage de programmation.

  

FLOW-MATIC, initialement connu sous le nom B-0 (version Business Language 0), est peut-être la première comme l'anglais langue de traitement de données . Il a été inventé et spécifié par Grace Hopper, et le développement de la variante commerciale a commencé à Remington Rand en 1955 pour le UNIVAC I. En 1958, le compilateur et sa documentation sont généralement disponibles et utilisés dans le commerce.

FLOW-MATIC a été l'inspiration derrière le Common Business Oriented Language , un des plus anciennes langues de programmation toujours en activité. Conformément à cet esprit, SEQUEL a été conçu avec la syntaxe anglaise comme (années 1970 est moderne, par rapport aux années 1950 et 1960).

En perspective, les systèmes de programmation « modernes » un accès encore des bases de données en utilisant l'âge de vieilles idées derrière

MULTIPLY PRICE BY QUANTITY GIVING COST.

Answer 2

Je pense que la manière dont une instruction SQL est structuré est logique dans la mesure où des phrases en anglais sont structurés. En gros

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

Je ne pense pas que cela fait beaucoup de sens, en anglais du moins, dire

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

Answer 3

Je suis en désaccord. grammaire SQL ne sont pas à l'envers.

De premier regard vous pouvez dire si la requête SELECT, INSERT, UPDATE ou DELETE données (tout le reste de SQL, par exemple DDL, omis exprès).

---

Retour à votre instruction SELECT confusion: Le but de SQL est d'être déclarative . Ce qui signifie que vous exprimer ce que vous voulez et comment vous le voulez. Il est donc tous les sens premier Etat CE QUE VOUS VOULEZ (liste des attributs que vous êtes sélectionnez ing) et puis fournir le SGBD avec un peu plus informations sur l'endroit où cela devrait être levé les yeux de.

Placer la clause WHERE à la fin fait un grand sens aussi: Imaginez un entonnoir large en haut, étroit en bas. En ajoutant une clause WHERE vers la fin de l'instruction, vous étouffent sur la quantité de données résultantes. L'application de restrictions à votre demande tout autre endroit que dans le fond, il faudrait le développeur de tourner la tête autour.

---

clause ORDER BY à la fin: une fois que les données ont passé par l'entonnoir, le tri

.

REJOINT (critères JOIN) appartiennent vraiment dans la clause FROM.

GROUPEMENT:. Les données en cours d'exécution essentiellement à travers un entonnoir avant qu'il pénètre dans une autre ampoule

sytax SQL est doux. Il n'y a rien à l'intérieur à ce sujet. Peut-être que la raison pour laquelle SQL est si populaire, même après tant de décennies. Il est assez facile à saisir et à donner un sens à. (Bien que je l'ai une fois fait face à une instruction SQL 7 pages (A4) qui m'a pris un certain temps pour obtenir ma tête autour.)

Answer 4

Il est conçu pour être l'anglais comme. Je pense que c'est la principale raison.

Comme une note de côté, je me souviens des premiers aperçus de LINQ ont été directement modélisés après (select ... from ...). Cela a été changé dans les aperçus plus tard pour être plus comme langage de programmation (de sorte que le champ d'application va vers le bas). Anders Hejlsberg spécifiquement mentionné ce fait bizarre à propos de SQL (ce qui rend plus difficile IntelliSense et ne correspond pas aux règles de portée C #) comme la raison pour laquelle ils ont pris cette décision.

Quoi qu'il en soit, bon ou mauvais, il est ce qu'il est et il est trop tard pour changer quoi que ce soit.

Answer 5

L'ordre des clauses SQL est tout à fait logique. Rappelez-vous que SQL est un langage déclaratif, où vous déclarez ce que vous voulez et le système devinera la meilleure façon de l'obtenir pour vous. La première clause est la clause select où vous listez les colonnes que vous voulez dans le tableau de résultats. Tel est l'objectif principal de la requête. Après avoir dit ce que vous voulez que le résultat ressemble, vous prochain état où les données doivent provenir. La clause where limite la quantité de données retournée. Il est inutile de penser à la façon de limiter vos données, sauf si vous savez d'où il vient, il va après la clause de. Le groupe par clause travaille avec les opérateurs d'agrégation dans la clause select et pourrait aller nulle part après la clause de mais il est préférable de penser à l'agrégation des données filtrées, il vient après la clause where. La clause having doit venir après le groupe par article. L'ordre par article est sur la façon dont les données sont présentées et pourrait aller nulle part après la sélection.

Answer 6

Il est compatible avec le reste de la syntaxe de SQL d'avoir chaque démarrage de l'instruction avec un verbe (CREATE, DROP, UPDATE, etc.).

L'inconvénient majeur d'avoir la liste des colonnes première est qu'il est gênant pour l'auto-complétion (comme Hejlsberg a mentionné), mais cela n'a pas été une préoccupation quand la syntaxe a été conçu dans les années 1970.

Nous aurions pu avoir le meilleur des deux mondes avec une syntaxe comme SELECT FROM SomeTable: ColumnA, ColumnB, mais il est trop tard pour le changer maintenant.

Quoi qu'il en soit, l'ordre de présentation de SELECT SQL n'est pas unique. Il correspond exactement à celui de la liste Python compréhensions:

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

Answer 7

Histoire de la langue de côté (bien qu'il est fascinant) Je pense que la chose vous manque est que SQL n'est pas de dire au système ce qu'il faut faire, tant que ce résultat final que vous voulez (et il figure comment le faire)

dire «aller là-bas pour ce rack, ramasser les chapeaux avec hatbands, chapeaux bleu, puis vert, puis rouge, et les amener à moi est très bien dit le système comment Faites ce que vous voulez. il est programmeur pense où nous présumons que le travailleur est très stupide et a besoin d'instructions détaillées minutieusement.

SQL commence avec le résultat final d'abord, les données que vous voulez, l'ordre des colonnes, etc .. il est très bien le point de vue de quelqu'un qui construit un rapport. « Je veux nom, prénom, puis l'âge, alors ..... » C'est après tout le but de faire la demande. Ainsi, il commence par cela, le format des résultats que vous voulez. Ensuite, il va dans où vous vous attendez à trouver les données, quels sont les critères à rechercher, l'ordre de le présenter, etc.

Donc, comme une alternative à préciser dans les moindres détails ce que vous voulez que le travailleur à faire, SQL peut présumer que le système sait comment faire, et des centres plus sur ce que vous voulez.

Ainsi, au lieu de dire pédante votre travailleur d'aller ici, obtenir ce, apportez là-bas .. il est plus comme dire: « Je veux des chapeaux, du support 12, qui ont hatbands, et s'il vous plaît les trier par couleur. »