Dlaczego w zapytaniu SQL wybrano opcję Select before the From? [Zamknięte]

To mnie bardzo martwiło w szkole.

Pięć lat temu, kiedy nauczyłem się języka SQL, zawsze zastanawiałem się, dlaczego najpierw określamy pola, które chcemy, a następnie skąd je chcemy.

Zgodnie z moim pomysłem powinniśmy napisać:

From Employee e
Select e.Name

Dlaczego więc norma mówi, co następuje?

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

Zrozumienie SQL zajęło mi kilka tygodni i wiem, że dużo czasu pochłonęła niewłaściwa kolejność elementów.

To jest jak pisanie w C #:

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

Zakładam więc, że ma to powód historyczny. Dlaczego?

Początkowo język SQL nazwano SEQUEL stojący na

• Structured English Query Language
  z naciskiem na angielski , zakładając, że jest on zbliżony do pisowni języka naturalnego .

Teraz przeliteruj te dwa stwierdzenia, tak jakbyś pisał angielskie zdania:

1. „Z tabeli pracowników e Wybierz kolumnę e.Name”
2. „Wybierz kolumnę e.Name z tabeli pracowników e”

Drugi brzmi bliżej naturalnego języka angielskiego, dlatego jest ustawiony jako norma.

BTW to samo rozumowanie dotyczy Whereitd. - Instrukcje SQL zostały celowo zaprojektowane tak, aby brzmiały zbliżone do języka naturalnego.

Ponieważ SELECT jest wymagany w instrukcji select, a FROM nie.

Select 'This String'

Oczywiście twoja instrukcja sql może zostać przeanalizowana w celu wyszukania instrukcji SELECT, DELETE, UPDATE po FROM, ale czy to naprawdę tak wielka sprawa?

Pamiętaj, że wszystko to zostało zrobione przed intellisense. To nie jest takie skomplikowane.

Edycja: Prawdopodobnie nie ma powodu, dla którego nie można było zbudować interpreterów języka SQL do wykonywania obu tych czynności.

Nie znam odpowiedzi, którą mógłbym poprzeć referencjami, ale gdybym musiał spekulować: SQL jest językiem deklaratywnym , instrukcja takiego języka opisuje to , co chciałbyś zrobić, a nie sposób , w jaki chcesz to zrobić.

Jako taki, „WYBIERZ X Z Y” brzmi jako bardziej odpowiedni sposób odpowiedzi na „Co chciałbym wybrać z bazy danych”, w przeciwieństwie do pisania „Z Y SELECT X”.

Ponadto w języku SQL instrukcja SELECT / UPDATE / INSERT określa typ operacji, którą zamierzasz wykonać, a FROM jest tylko klauzulą, która pomaga wybrać odpowiednią tabelę w bazie danych. Ponownie, to , co robisz z danymi, ma pierwszeństwo przed tym , jak dokładnie to osiągniesz.

SQL jest strukturalnym językiem zapytań skierowanym do osób posługujących się językiem angielskim. WYBIERZ, WSTAW, AKTUALIZUJ i USUŃ są poleceniami rozkazującymi. W języku angielskim polecenia rozkazujące rozpoczynają zdanie lub wyrażenie. Porównać:

West young man go!

do

Go west young man!

SQL jest zgodny z drugim (imperatywnym) formatem. Również cztery polecenia rozkazowe mają trzy znacząco różne formaty. Rozważać:

FROM    employees a,
        accounts b
UPDATE  ...

lub

INTO    customers a
SELECT  ...

Jeśli znasz podejmowane działanie, łatwiej wybrać odpowiedni format.

W przypadku select określasz, które atrybuty chcesz, a następnie dodajesz tabele, które je mają. Podczas budowania kryteriów wyboru możesz dodawać dodatkowe tabele. W przypadku dynamicznego dodawania kryteriów zwykle można to zrobić na końcu statycznej części zapytania.

Instrukcje SQL zaczynają się od czasowników. To był wybór projektantów języków i tak działa wiele języków programowania. Semantycznie często zdarza się, że języki programowania działają w ten sposób:

verb(noun, noun, noun);

Również w przypadku instrukcji SELECT podanej jako przykład proponowana składnia umieści obiekt na pierwszym miejscu w instrukcji. Zamiast kolejności zdań VSO (czasownik, temat, obiekt) miałbyś OVS, co byłoby bardzo dziwne w porównaniu do języków naturalnych. SVO (np. Angielski), VSO (np. Arabski) i SOV (np. Łaciński) są bardziej rozsądnymi przybliżeniami ludzkiej mowy.

Myślę, że znacznie skomplikowałoby to parsowanie, szczególnie przy podzapytaniach, np

  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

Analiza tego byłaby bardziej skomplikowana. Nie można było stwierdzić, że AKTUALIZACJA była błędem składni, dopóki nie przeanalizowano klauzuli FROM, a analizator składni musiałby zapamiętać wystarczający kontekst, aby wiedzieć, że analizuje podzapytanie. Nie wydaje mi się, aby aktualizacje były w każdym razie dopuszczalne w podzapytaniach, ale gdyby były (być może z klauzulą ​​RETURNING), możesz nie być w stanie stwierdzić, że było to nieprawidłowe, dopóki nie przeanalizujesz instrukcji SELECT.

Zwiększy to przynajmniej k (gramatycznie) gramatyki, aw najgorszym uczyni ją wrażliwą na kontekst, chociaż przesuwa to granice moich raczej słabo zapamiętanych prac projektowych kompilatorów z uniwersytetu.