2009-07-20 5 views

risposta

1

In generale, poiché senza estensioni della sintassi (ad esempio PL/SQL, T-SQL), non è possibile scrivere funzioni.

Ma è certamente molto orientato all'espressione, che è una caratteristica che ha in comune con i linguaggi funzionali.

8

Le funzioni sono oggetti di prima classe in SQL? difficilmente. Quindi direi di no.

+0

per definizione - no, ma simile per il modo di pensare (e il debug) – ren

+1

Ogni query SQL è una funzione. Forse non ti piace la sintassi. –

+0

Sì, lo sono ... SELEZIONA è una funzione. Se leggi dell'algebra relazionale, sapresti che SELEZIONE e PROIEZIONE sono funzioni/azioni. Semplicemente non lo vedi scritto come 'Seleziona (colonne/espressioni)'; –

0

Poiché il punto di un linguaggio funzionale è che si programma con, beh, funzioni, direi di no. SQL sta programmando con le relazioni (se si può anche chiamare SQL un linguaggio di programmazione - nella sua forma base, SQL non è completato da Turing).

2

Non esiste un'unica definizione reale di cosa sia un linguaggio funzionale (o, peraltro, di quello procedurale o orientato agli oggetti).

Ma non riesco a pensare molto a ciò che indica che SQL è funzionale. Non ha funzioni, non ha ricorsione, non ha chiusure, non ha funzioni annidate, non ha funzioni come tipi di prima classe.

Una domanda più frequente è se SQL è un linguaggio di programmazione per tutto. Non è completo.

+1

+1 per il non completamento completo - Volevo solo aggiungere alla mia risposta :-( –

+1

Lo standard SQL92 non è completo. Il T/SQL di Oracle e PL/SQL e SQL Server sono completi. –

+0

sì, ma la domanda riguardava SQL stesso, non le estensioni dei vari fornitori – jalf

5

Penso che i linguaggi SQL e quelli funzionali siano molto diversi l'uno dall'altro. In un linguaggio funzionale il calcolo viene eseguito valutando le funzioni. Le funzioni non cambiano stato. Tutto quello che fanno è calcolare un valore dai loro argomenti. Le altre parole, le funzioni non causano effetti collaterali. Le lingue funzionali sono di uso generale.

SQL è un linguaggio progettato per gestire sistemi di gestione di database relazionali. Può essere visto come una lingua specifica di dominio. È progettato per funzionare su "set" di dati. Può mutare lo stato globale (cioè il database) usando comandi come UPDATE. Non esiste un concetto di funzioni che viene valutato su un valore. Per quanto ho capito, SQL non è nemmeno completo di Turing.

+1

Le lingue funzionali devono in qualche modo causare effetti collaterali, non è così? –

+0

Ma F # ha lo stato, corretto? –

21

SQL è stato progettato come un linguaggio dichiarativo, nel senso che dici what si vuole ottenere e il motore SQL decide how.

Tuttavia, SQL opera su insiemi, ei risultati delle funzioni possono essere insiemi di prima classe in Oracle, SQL Server e PostgreSQL.

Si può dire che SQL è un linguaggio funzionale, purché una funzione accetta un set come input e produce un set come output.

Cioè, si può scrivere qualcosa di simile:

SELECT * 
FROM mytable t 
JOIN myfunction(x) f 
ON  f.col1 = t.col2 

, o anche questo:

SELECT * 
FROM mytable t 
CROSS APPLY 
     myfunction(t.col2) f 

(in SQL Server)

o questo:

SELECT t.*, myfunction(t.col2) 
FROM mytable t 

(in PostgreSQL)

Questa non è una parte dello standard SQL, tuttavia.

Proprio come un compilatore C++ cerca di trovare un modo ottimale per moltiplicare due float s (in termini di algebra pianura), SQL ottimizzatore cerca di trovare un modo ottimale per moltiplicare due set (in termini di algebra relazionale).

In C++, è sufficiente scrivere a * b e fare affidamento sul compilatore per generare un assembly ottimale per questo.

In SQL, si scrive SELECT * FROM a NATURAL JOIN b e si basa sull'ottimizzatore.

Tuttavia, con tutta la dichiaratività dichiarata SQL (nessun gioco di parole previsto), la maggior parte degli ottimizzatori reali è in grado di eseguire solo riscritture di query molto semplici.

Say, non ottimizzatore io sappia è in grado di utilizzare lo stesso piano efficiente per questa query:

SELECT t1.id, t1.value, SUM(t2.value) 
FROM mytable t1 
JOIN mytable t2 
ON  t2.id <= t1.id 
GROUP BY 
     t1.id, t1.value 

e per questo uno:

SELECT id, value, SUM(t1.value) OVER (ORDER BY id) 
FROM mytable 

, per non parlare della più complessa interrogazioni.

Ecco perché è ancora necessario formulare le query in modo che utilizzino un piano efficiente (pur continuando a produrre lo stesso risultato), rendendo così SQL un po 'meno di una lingua dichiarativa.

Recentemente ho fatto posto nel mio blog su questo:

+0

per essere funzionale, una funzione dovrebbe essere consentita a prendere una funzione come input però. semplicemente permettere alle funzioni di esistere è appena sufficiente. – jalf

+4

@jalf: come in 'functionA (x) CROSS APPLY functionB (functionA.col1)'? – Quassnoi

5

dichiarativa e funzionale? Quello sarebbe un foglio di calcolo.

8

No, SQL non è un linguaggio funzionale. Il paradigma è un po 'diverso. Si noti che esistono altri tipi di linguaggi di programmazione dichiarativi diversi da quelli funzionali: l'esempio canonico è la programmazione logica e PROLOG.

Tecnicamente, Algebra relazionale (la base teorica di SQL) non è attualmente completa. Sebbene i dialetti SQL moderni aggiungano abbastanza funzioni procedurali in modo che uno possa implementare stored procedure e siano completati a questo livello, una singola query SQL non è un calcolo completo. Algebra relazionale ha la proprietà della pienezza di Dio.La completezza di Godel implica la capacità di esprimere qualsiasi computazione che possa essere definita in termini di calcolo del predicato del primo ordine - fondamentalmente ciò che si vorrebbe sapere come espressioni logiche ordinarie.