Domanda

In quasi tutti gli insiemi di informazioni strutturati formalmente, si inizia a leggere dall'inizio verso la fine, o occasionalmente dalla fine verso l'inizio (indirizzi stradali, ad esempio). Ma in SQL, in particolare le query SELECT, per comprendere correttamente il suo significato devi iniziare dal centro, dalla clausola FROM.Ciò può rendere molto difficile la lettura delle query lunghe, soprattutto se contengono query SELECT annidate.

Di solito nella programmazione, quando qualcosa sembra non avere alcun senso, dietro c'è una ragione storica.Iniziare con SELECT invece che con FROM non ha senso.Qualcuno sa il motivo per cui è fatto in questo modo?

È stato utile?

Soluzione

La voce SQL Wikipedia descrive brevemente un pò di storia:

  

Nel corso del 1970, un gruppo a IBM di San Jose Research Laboratory ha sviluppato il sistema di gestione di database relazionali sistema R, basato sul modello introdotto da Edgar F. Codd nel suo articolo influente, "un modello relazionale dei dati per le grandi banche di dati condivisi ". Donald D. Chamberlin e Raymond F. Boyce di IBM in seguito creato la Structured Query Language Inglese (SEQUEL) per manipolare e gestire i dati memorizzati nel sistema R. L 'acronimo SEQUEL fu poi cambiato in SQL perché "Sequel" era un marchio di fabbrica della società velivoli Hawker Siddeley sede nel Regno Unito.

Il nome originale esplicitamente menzionato English , che spiega la sintassi.

Scavando un po 'più a fondo, troviamo la FLOW-MATIC linguaggio di programmazione.

  

FLOW-MATIC, originariamente conosciuto come B-0 (Versione in lingua 0), è forse la prima lingua inglese come l'elaborazione dei dati . E 'stato inventato e specificato da Grace Hopper, e lo sviluppo della variante commerciale è iniziata alle Remington Rand nel 1955 per l'UNIVAC I. Nel 1958, il compilatore e la relativa documentazione sono stati generalmente disponibili e utilizzati in commercio.

FLOW-MATIC è stata l'ispirazione dietro la lingua aziendali comuni Oriented , uno dei più antichi linguaggi di programmazione ancora in uso attivo. Mantenendo con questo spirito, SEQUEL è stato progettato con l'inglese come la sintassi (1970 è moderno, rispetto a 1950 e 1960).

In prospettiva, "moderni" sistemi di programmazione accedono ancora database utilizzando l'età vecchie idee dietro

MULTIPLY PRICE BY QUANTITY GIVING COST.

Altri suggerimenti

Credo che il modo in cui è strutturato un'istruzione SQL senso logico, per quanto frasi in inglese sono strutturati. Fondamentalmente

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

Non credo che abbia molto senso, In inglese, almeno, dire

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

Non sono d'accordo.La grammatica SQL non è al rovescio.

Dal primissimo sguardo puoi dire se la query SELEZIONE, INSERT, AGGIORNA o ELIMINA i dati (tutto il resto di SQL, ad es.DDL, volutamente omesso).


Torniamo alla confusione dell'istruzione SELECT:Lo scopo di SQL è essere dichiarativo.Il che significa che esprimi QUELLO che vuoi e non COME lo vuoi.Quindi ha tutto senso farlo Primo dichiara COSA VUOI (elenco degli attributi che sei Selezionareing) e Poi fornire al DBMS alcune informazioni aggiuntive su dove cercare DA.

Anche posizionare la clausola WHERE alla fine ha molto senso:Immagina un imbuto, largo in alto, stretto in basso.Aggiungendo una clausola WHERE verso la fine dell'istruzione, riduci la quantità di dati risultanti.Applicare restrizioni alla tua query in un posto diverso da quello in basso richiederebbe allo sviluppatore di voltare la testa.


Clausola ORDER BY alla fine:una volta che i dati sono passati attraverso l'imbuto, ordinali.

I JOINS (criteri JOIN) appartengono realmente alla clausola FROM.

RAGGRUPPAMENTO:fondamentalmente eseguendo i dati attraverso un imbuto prima che entrino in un altro imbuto.

La sitassi SQL è dolce.Non c'è niente al riguardo.Forse è per questo che SQL è così popolare anche dopo così tanti decenni.È piuttosto facile da afferrare e dargli un senso.(Anche se una volta mi sono trovato di fronte a un'istruzione SQL di 7 pagine (formato A4) che mi ha richiesto un po' di tempo per capire.)

E 'stato progettato per essere inglese come. Penso che questo sia il motivo principale.

Come nota a margine, mi ricordo le anteprime iniziali di LINQ sono stati direttamente modellati dopo (select ... from ...). Questo è stato cambiato in anteprime successive per essere più linguaggio di programmazione come (in modo che il campo di applicazione va verso il basso). Anders Hejlsberg specificamente menzionato questo fatto strano in SQL (che rende più difficile e IntelliSense non corrisponde regole # ambito C) come la ragione per cui ha preso questa decisione.

In ogni caso, bene o male, è quello che è e che è troppo tardi per cambiare qualcosa.

L'ordine delle clausole in SQL è assolutamente logico. Ricordate che SQL è un linguaggio dichiarativo, in cui si dichiara ciò che si desidera e il sistema capisce il modo migliore per farlo per voi. La prima clausola è la clausola select in cui si elencano le colonne che si desidera nella tabella dei risultati. Questo è lo scopo primario della query. Dopo aver affermato ciò che si desidera che il risultato a guardare come, è stato successivo in cui i dati devono venire da. La clausola in cui limita la quantità di dati che vengono restituiti. Non ha senso nel pensare a come limitare i dati a meno che non si sa da dove viene, così si va dopo la clausola from. La clausola GROUP BY lavora con gli operatori di aggregazione nella clausola select e potrebbe andare da nessuna parte, dopo la clausola FROM però è meglio pensare di aggregazione sui dati filtrati, quindi viene dopo la clausola dove. La clausola having deve venire dopo che il gruppo dalla clausola. La clausola ORDER BY è su come i dati vengono presentati e potrebbe andare da nessuna parte dopo la selezione.

E 'coerente con il resto della sintassi di SQL di avere ogni avvio dichiarazione con un verbo (CREATE, DROP, UPDATE, ecc.).

Il principale svantaggio di avere l'elenco delle colonne prima è che è scomodo per il completamento automatico (come Hejlsberg ha menzionato), ma questo non era un problema quando la sintassi è stata progettata nel 1970.

Avremmo potuto avere il meglio dei due mondi con una sintassi simile SELECT FROM SomeTable: ColumnA, ColumnB, ma è troppo tardi per cambiare ora.

In ogni caso, SELECT fine la dichiarazione di SQL non è unica. Essa corrisponde esattamente a quella della lista Python comprehensions:

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

Storia della lingua da parte (anche se è affascinante) Penso che la cosa si sta perdendo è che SQL non si tratta di dire al sistema che cosa fare, così tanto come quello risultato finale che si desidera (e si capisce come farlo)

dicendo 'andare laggiù a quel rack, raccogliere i cappelli con hatbands, cappelli blu, poi verde, poi rosso, e portarli a me' è molto dicendo il sistema di come per Fai quello che vuoi. è programmatore pensare , dove si presume il lavoratore è molto stupido e ha bisogno di istruzioni minuziosamente dettagliate.

SQL sta iniziando con il risultato finale prima, i dati che si desidera, l'ordine delle colonne, ecc .. è molto il punto di vista di qualcuno che sta costruendo un rapporto. "Voglio nome, cognome, quindi l'età, quindi ....." Questo è dopo tutto lo scopo di rendere la richiesta. Così si comincia con questo, il formato dei risultati desiderati. Poi si va in cui ci si aspetta che per trovare i dati, quali criteri cercare, la fine di presentarlo, ecc.

Così come alternativa a specificare nei minimi dettagli ciò che si desidera che il lavoratore di fare, SQL presume il sistema sa come fare, e centri di più su ciò che si desidera.

Così, invece di dire al vostro pedantically lavoratore di andare qui, ottenere questo, portarla lì .. è più come dire: "Voglio cappelli, dalla cremagliera 12, che hanno hatbands, e si prega di ordinarli in base al colore."

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top