Perché SQL è noto come linguaggio basato sulle relazioni / funzionale?

We're learning that most languages are classified as either of the two, "relation based" or "high level".

Questi concetti sono ortogonali. "Relation-based" significa che la semantica del linguaggio si basa sul concetto di una relazione, cioè un'associazione molti a molti tra due insiemi (le relazioni sono il fondamento matematico dietro le tabelle SQL). "Alto livello" significa che la lingua contiene molte astrazioni che nascondono molti dei dettagli tecnici sottostanti (come posizioni di memoria, registri della CPU, accesso al disco, operazioni bit a bit, ecc.). SQL è certamente basato sulla relazione, in quanto il suo scopo principale è quello di descrivere i dati relazionali e le operazioni su di esso. SQL è anche abbastanza alto livello; non fornisce alcun mezzo per accedere direttamente ai byte sul disco, e non ti dice alcun dettaglio su come memorizza i suoi dati (almeno lo standard SQL non lo fa, la maggior parte dei fornitori fornisce estensioni allo standard che possono darti un po 'di informazioni, ma questo è accanto al punto).

In realtà, ci sono molti più assi lungo i quali le lingue di programmazione (e dati) possono essere classificate; uno particolarmente interessante è dichiarativo vs imperativo . Le lingue dichiarative descrivono che cosa è ; le lingue imperative descrivono come fare qualcosa. La parte DDL di SQL è per lo più dichiarativa, nonostante le parole chiave dall'aspetto imperativo (" CREATE TABLE ", " DROP DATABASE ", ecc.) E persino la parte di manipolazione dei dati ( SELECT , UPDATE , INSERT , DELETE ) è ancora piuttosto dichiarativo. Una proprietà molto interessante di SQL è che non è completa Turing: non è possibile scrivere un loop illimitato in SQL ANSI standard semplice.

programmi di programmazione attorno a poche idee chiave:

Le funzioni
• sono cittadini di prima classe (cioè possono essere utilizzate come valori, come input per altre funzioni e come output da altre funzioni)
• funzioni di ordine superiore (funzioni che operano su funzioni o funzioni che restituiscono funzioni)
• purezza (una funzione pura è una che non ha effetti collaterali, una funzione pura non può fare alcun I / O, non può leggere né modificare nessuno stato globale e non può accettare argomenti di riferimento non const. perché produrranno sempre lo stesso risultato dato gli stessi input)

SQL certamente non ruota attorno alle funzioni come strumento principale per modellare le cose, ma abbraccia in qualche modo l'idea di purezza: la stessa query eseguita sullo stesso database produrrà sempre lo stesso risultato (tranne che per gli ordini). Chiamare SQL un linguaggio 'funzionale' è un po 'eccessivo anche se IMO.

SQL non è un imperativo perché il processo di HOW query e relazioni non sono definiti dal programmatore, ma dal compilatore / ottimizzatore / interprete. SQL è una lingua dichiarativa - In SQL, si dichiarano le relazioni. Questo crea una struttura dati (che di nuovo non è fisicamente definita con la lingua ma dalla sua implementazione) utilizzando inserimenti, aggiornamenti ed eliminazioni.

L'uso delle relazioni viene quindi eseguito utilizzando le query (istruzioni SELECT), che sono funzionali in quanto non hanno effetti collaterali.

Il tutto è racchiuso nel modello relazionale .

SQL non è tanto un linguaggio funzionale quanto è dichiarativo. I linguaggi funzionali, in generale, enfatizzano lo stile dichiarativo piuttosto che l'imperativo per minimizzare gli effetti collaterali. Ciò potrebbe portare alcune persone a fare riferimento a SQL come funzionale, ma non è accurato. È dichiarativo con elementi procedurali.

È possibile che le tue note siano criptate?

Non ho mai sentito parlare di linguaggi di programmazione divisi tra "relazione basata" e "alto livello". Basso livello / Alto livello viene solitamente utilizzato per distinguere l'assemblatore e il C dalle lingue che forniscono supporto diretto per strutture più astratte. Le relazioni sono una struttura piuttosto astratta, quindi direi che qualsiasi cosa supporti le relazioni è ad alto livello per definizione.

SQL puro viene solitamente descritto come un linguaggio dichiarativo, con alcune parti procedurali attaccate dai vari fornitori. Il fatto che SQL non supporti funzioni come variabili mi sembra immediatamente squalificato dall'essere un linguaggio funzionale.

SQL è un linguaggio relazionale, basato su set, su cui sono state applicate funzionalità procedurali.

Non so se considererei funzionale SQL, ma ha alcuni aspetti dei linguaggi funzionali. Le varianti moderne di SQL (con i bit procedurali) non sono assolutamente funzionali.

Penso che SQL sia uno zucchero sintattico attorno all'algebra relazionale + qualcosa in più. L'algebra relazionale ha un sacco di potere dei linguaggi funzionali, infatti fa leva su funzioni di altissimo potere espressivo (selezione, proiezione, ridenominazione, unione, unione, intersezione ...). Ma per quanto ne so, il trattamento di base dell'algebra relazionale di solito non ha equivalenti all'operatore lambda, sebbene possa essere esteso con un operatore di ricorsione in modo trasparente.

Penso che l'algebra delle relazioni sia piuttosto un linguaggio algebrico. SQL, con le sue sottoquery, si è spostato dalla pura algebra relazionale verso uno stile più funzionale, ma senza un operatore lambda, penso che non sia un linguaggio pienamente funzionale. Non so se possa essere esteso a un linguaggio funzionale completo in modo trasparente, non sono esperto in questo campo. Haskell ha alcune librerie con l'obiettivo di linguaggi di database di alto livello.

Non conosco tutte le sottigliezze di ciò di cui ha bisogno perché un linguaggio sia qualificato come funzionale, ma Sql Server ha introdotto un modo molto interessante per lavorare con le funzioni. Una clausola speciale rende le funzioni in grado di interagire insieme in una query. Si chiama Applica. Quando ho spiegato questo ad un ex programmatore di APL, mi ha detto che esisteva una clausola simile in APL per un obiettivo simile. La clausola Apply consente di passare set di attributi dalla riga di una tabella o da una funzione della tabella come input per un'altra funzione. Detto questo, ho imposto una restrizione sul tipo di funzione della tabella da scrivere per essere considerata funzionale. Il deve essere dichiarato come inline, che significa essere espresso come una singola istruzione select. Questo impone di non avere variabili. Tali query con un sacco di logica possono essere scritte, fornire le espressioni di tabella comuni che consentono di trasformare le espressioni in colonna, una sorta di variabile immutabile che può essere riutilizzata in altri CTE. Alla fine, la funzione diventa una macro molto grande che rende l'ottimizzatore libero di ottimizzare il modo in cui è necessario. L'unica cosa che manca alla gente sono alcuni semplici trucchi per scrivere la logica condizionale e dichiarare alcuni dati supportlogic nella query. Infine alcune funzioni che usano la clausola over sono necessarie come un modo per portare i risultati come un valore utilizzabile in una riga da altre righe, ma sarebbe un po 'lungo da elaborare qui.