Pourquoi la sélection avant le de dans une requête SQL? [fermé]


67

C'est quelque chose qui m'a beaucoup dérangé à l'école.

Il y a cinq ans, lorsque j'ai appris le langage SQL, je me suis toujours demandé pourquoi nous spécifions d'abord les champs que nous souhaitons et ensuite d'où nous les voulions.

Selon mon idée, nous devrions écrire:

From Employee e
Select e.Name

Alors pourquoi la norme dit ce qui suit?

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

Il m'a fallu des semaines pour comprendre SQL et je sais qu'une bonne partie de ce temps a été consommée par le mauvais ordre des éléments.

C'est comme écrire en C #:

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

Donc, je suppose que cela a une raison historique. Pourquoi?


64
C'est une conspiration de la DBA de garder les singes OO à leur place.
gbn

3
Malheureusement, je ne trouve aucune information pertinente dans le document qui a introduit SEQUEL et je ne pense pas que des citations spécifiques répondent à votre question. La réponse de gnat est peut-être la meilleure explication, mais je ne rejeterais pas la théorie du complot.
Yannis

2
Personnellement, j'ai toujours souhaité Linqne pas avoir utilisé la SQLsyntaxe standardisée .
jp2code

4
Les clauses d'une instruction SELECT ne sont pas l'ordre de l'opération.
S.Lott

8
Bonne question. Vous devez ensuite expliquer pourquoi les requêtes INSERT et UPDATE doivent utiliser différents modèles de syntaxe: (champ1, champ2) VALEURS (f1, f2) vs (champ1 = f1, champ2 = f2).
LarsTech

Réponses:


86

A l'origine, le langage SQL s'appelait SEQUEL pour

  • Langage d'interrogation anglais structuré
    mettant l'accent sur l' anglais , en supposant qu'il soit proche de l'orthographe du langage naturel .

Maintenant, épelez ces deux déclarations comme vous épeleriez des phrases en anglais:

  1. "De la table des employés e Sélectionnez la colonne e.Name"
  2. "Sélectionnez la colonne e.Nom de la table des employés e"

La seconde sonne plus proche de la langue anglaise naturelle, c’est la raison pour laquelle elle est définie comme norme.

En outre, le même raisonnement s'applique à BTW Where- les instructions SQL ont été intentionnellement conçues pour donner un son proche du langage naturel.


7
Bien sûr, Microsoft a ignoré cela avec LINQ, car le premier vient en premier!

27
Il y a beaucoup de logique en anglais: /
Michael K

15
@ Digger - de par leur conception: ils ne pouvaient pas supporter intellisense dans la partie select si la sélection arrivait en premier.
Scott Whitlock

6
@ Digger: LINQ suit le OO / modern Object.Method ou Object.Property. N'oubliez pas que SQL existe depuis 40 ans
gbn

7
J'aurais dû poster cette question sur english.stackexchange.com à la place :)
Cyril Gandon

37

Parce que SELECT est requis dans une instruction select et que FROM ne l’est pas.

Select 'This String'

Bien sûr, votre déclaration sql peut être analysée pour rechercher SELECT, DELETE, UPDATE après le FROM, mais l’affaire est-elle vraiment si grosse?

Rappelez-vous, tout cela était fait avant intellisense. Ce n'est pas si compliqué.

Edit: Il n'y a probablement aucune raison pour que les interprètes SQL ne puissent pas être construits pour faire les deux.


2
Cependant, vous pouvez aussi écrire à la FROM myTable;place de FROM myTable SELECT *; Cela semble être une exigence, car c'est ce à quoi vous étiez habitué.
user606723

13
Ce n’est pas parce que cela est nécessaire que cela doit venir en premier.
LarsTech

8
En ANSI, SQL FROMest requis. C'est pourquoi de nombreux SGBDR ont une table appelée DUAL ou une autre table fictive à une seule ligne
Martin Smith

@LarsTech - il n'est pas nécessaire que ce soit la première, mais pourquoi compliquer les choses. C'est ce qu'on appelle une instruction select, commencez simplement par le mot select.
JeffO

3
@ JeffO: D'accord. SELECT FROM Customers COLUMNS FirstName, LastName, PhoneNumber.
Allon Guralnek

10

Je ne connais pas une réponse que je pourrais sauvegarder par des références, mais si je devais spéculer: SQL est un langage déclaratif , une déclaration de ce langage décrit ce que vous souhaitez faire et non la façon dont vous souhaitez le faire.

En tant que tel, "SELECT X FROM Y" semble être un moyen plus approprié de répondre à "Que voudrais-je sélectionner dans la base de données", par opposition à l'écriture "FROM Y SELECT X".

De plus, en SQL, SELECT / UPDATE / INSERT spécifie le type d'opération que vous êtes sur le point d'effectuer et FROM n'est qu'une clause qui vous aide à faire une sélection dans la bonne table de la base de données. Encore une fois, que faites-vous avec les données a préséance sur la manière dont vous allez y parvenir?


1
+1: Ce n'est pas impératif ou procédural. L'ordre des clauses est simplement un ajustement avec l'anglais. Rien de plus.
S.Lott

ON et WHERE sont peut-être de meilleurs exemples de l'importance de l'ordre des clauses dans une instruction select.
JeffO

5

SQL est un langage de requête structuré destiné aux anglophones. SELECT, INSERT, UPDATE et DELETE sont des commandes impératives. En anglais, les commandes impératives commencent la phrase ou la déclaration. Comparer:

West young man go!

à

Go west young man!

SQL suit le deuxième format (impératif). De plus, les quatre commandes impératives ont trois formats très différents. Considérer:

FROM    employees a,
        accounts b
UPDATE  ...

ou

INTO    customers a
SELECT  ...

Si vous connaissez l'action que vous entreprenez, il est plus facile de sélectionner le format correct.

Dans le cas de select, vous déterminez les attributs de votre choix, puis ajoutez les tables qui les contiennent. Lorsque vous établissez les critères de sélection, vous pouvez ajouter des tables supplémentaires. Lorsque vous ajoutez des critères de manière dynamique, vous pouvez généralement le faire à la fin d'une partie statique de la requête.


7
Donc, Yoda n'était pas impliqué dans le développement de SQL.
Adam f

Intéressant que vous apportez UPDATE. UPDATE ... FROMn'est pas une structure de type anglais, IMO. Pas que j'ai de meilleures suggestions ...
Robert Brown

L'intention était de souligner que la préposition doit correspondre au verbe.
BillThor

3

Les instructions SQL commencent par des verbes. C’était le choix des concepteurs de langage, et de nombreux langages de programmation fonctionnent de cette façon. Sémantiquement, il n'est pas rare de voir des langages de programmation qui fonctionnent comme ceci:

verb(noun, noun, noun);

De plus, dans le cas de l'instruction SELECT que vous donnez à titre d'exemple, la syntaxe proposée placerait l'objet en premier dans l'instruction. Au lieu d'un ordre de phrases VSO (verbe, sujet, objet), vous auriez OVS, ce qui serait très étrange par rapport aux langues naturelles. SVO (par exemple l'anglais), VSO (par exemple l'arabe) et SOV (par exemple le latin) sont des approximations plus raisonnables du langage humain.


2

Je pense que cela compliquerait considérablement l'analyse, en particulier avec les sous-requêtes, par exemple

  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

L'analyse serait plus compliquée. Vous ne pouviez pas dire que UPDATE était une erreur de syntaxe jusqu'à ce que vous ayez analysé la clause FROM, et l'analyseur devrait se rappeler suffisamment de contexte pour savoir qu'il analysait une sous-requête. De toute façon, je ne pense pas que les mises à jour soient autorisées dans les sous-requêtes, mais si elles l'étaient (peut-être avec une clause RETURNING), vous pourriez ne pas être en mesure de dire que cela n'était pas valide avant d'avoir analysé l'instruction SELECT.

Cela augmenterait au moins le k (lookahead) de la grammaire et, au pire, le rendrait sensible au contexte, même si cela repoussait les limites de mes travaux de conception de compilateur de l'université, dont je me souviens très peu.


En regardant l'article de Wiki QUELqui a été développé à peu près au même moment, l'ordre des clauses de syntaxe est ce que suggère le PO.
Martin Smith
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.