Database.Guide

Forse hai incontrato le funzioni T-SQL PARSE(), CAST() e CONVERT() quando lavori con SQL Server e ti sei chiesto quale sia la differenza. Tutte e tre le funzioni sembrano fare la stessa cosa, ma ci sono sottili differenze tra loro.

In questo articolo mi propongo di delineare le principali differenze tra queste funzioni.

Confronto

Ecco una tabella che delinea le principali differenze tra le funzioni CONVERT(), CAST() e PARSE() in SQL Server:

	CONVERT()	CAST()	PARSE()
Definizione ufficiale	Converte un’espressione di un tipo di dati in un altro.	Converte un’espressione di un tipo di dati in un altro.	Ritorna il risultato di un’espressione, tradotto al tipo di dati richiesto in SQL Server.
Valore accettato	Qualsiasi espressione valida.	Qualsiasi espressione valida.	String.
Return Value	Secondo argomento, tradotto al tipo di dati richiesto come fornito dal 1° argomento.	1° argomento, tradotto al tipo di dati richiesto come fornito dal 2° argomento.	1° argomento, tradotto al tipo di dati richiesto come fornito dal 2° argomento.
Conversioni supportate	Tra due tipi di dati qualsiasi.	Tra due tipi di dati qualsiasi.	Solo da stringa a data/ora e numero.
Accetta l’argomento stile?	Sì.	No.	No.
Accetta l’argomento cultura?	No.	No.	Sì.
Richiede .NET Framework?	No.	No.	Sì.

Alcuni altri punti in aggiunta alla tabella precedente:

• La documentazione Microsoft sottolinea che PARSE() non sarà rimosso (poiché dipende dalla presenza del CLR). Remotizzare una funzione che richiede il CLR causerebbe un errore sul server remoto.
• Ci sono alcuni valori che PARSE() può trattare ma CAST() e CONVERT() no (per esempio, stringhe che usano certi formati di data).
• CAST() è incluso nello standard ANSI SQL-92.
• Alcuni sostengono che CAST() ha prestazioni migliori degli altri due.
• C’è un certo sovraccarico di prestazioni quando si analizzano i valori delle stringhe. Pertanto, PARSE() sarà tipicamente più lento degli altri due.

Di seguito ci sono esempi di situazioni in cui ogni funzione sarebbe la più adatta.

Quando usare CAST()

Si potrebbe fare un buon argomento per usare CAST() per qualsiasi scenario che non sia elencato sotto. Come menzionato, CAST() fa parte dello standard ANSI SQL da SQL-92, quindi dovrebbe essere più portabile tra diversi DBMS (se questo è un requisito).

Inoltre, alcuni sostengono che CAST() ha prestazioni migliori delle altre due (ecco un interessante articolo che confronta le prestazioni tra tutte e tre le funzioni).

Tuttavia, ci sono anche valide ragioni per cui potreste preferire (o avere bisogno) di usare CONVERT() rispetto a CAST().

Quando usare CONVERT()

La funzione CONVERT() può essere utile quando avete bisogno di usare l’argomento style per specificare come la data dovrebbe essere formattata durante la conversione tra una data e una stringa. Ecco alcuni esempi:

DECLARE @date datetime2 = '2018-06-07 02:35:52.8537677';SELECT CONVERT(nvarchar(30), @date, 100) AS '100', CONVERT(nvarchar(30), @date, 101) AS '101', CONVERT(nvarchar(30), @date, 102) AS '102', CONVERT(nvarchar(30), @date, 103) AS '103';

Risultato:

+---------------------+------------+------------+------------+| 100 | 101 | 102 | 103 ||---------------------+------------+------------+------------|| Jun 7 2018 2:35AM | 06/07/2018 | 2018.06.07 | 07/06/2018 |+---------------------+------------+------------+------------+

Lo puoi fare solo con CONVERT() perché:

• CAST() non supporta l’argomento style; e
• PARSE() non converte da una data/ora a un valore stringa (anche questo non supporta l’argomento style)

Quando usare PARSE()

Nonostante i vari svantaggi di questa funzione (prestazioni, dipendenza da .NET, conversioni limitate del tipo di dati), ha anche alcuni vantaggi, e ci sono alcuni scenari in cui potrebbe essere la vostra unica scelta. Ad esempio, quando si fornisce una data che include il nome del giorno della settimana, come venerdì 20 luglio 2018.

Quando gli altri restituiscono un errore

Ecco degli esempi in cui PARSE() è l’unica funzione delle tre che può convertire con successo il valore senza lanciare un errore.

In questi esempi, tentiamo di convertire vari valori stringa in un tipo di dati di data. Tuttavia, i valori di stringa che forniamo includono il nome del giorno della settimana. Questo causa problemi per CAST() e CONVERT(), ma PARSE() non ha problemi.

PARSE()

SELECT PARSE('Friday, 20 July 2018' AS date) AS 'Result 1', PARSE('Fri, 20 July 2018' AS date) AS 'Result 2', PARSE('Friday 20 July 2018' AS date) AS 'Result 3';

Risultato:

+------------+------------+------------+| Result 1 | Result 2 | Result 3 ||------------+------------+------------|| 2018-07-20 | 2018-07-20 | 2018-07-20 |+------------+------------+------------+

Quindi PARSE() non ha problemi con il formato della data che forniamo.

CONVERT()

SELECT CONVERT(date, 'Friday, 20 July 2018') AS 'Result 1', CONVERT(date, 'Fri, 20 July 2018') AS 'Result 2', CONVERT(date, 'Friday 20 July 2018') AS 'Result 3';

Risultato:

Conversion failed when converting date and/or time from character string.

Quindi CONVERT() non è in grado di convertire la stringa quando è in tale formato.

CAST()

SELECT CAST('Friday, 20 July 2018' AS date) AS 'Result 1', CAST('Fri, 20 July 2018' AS date)AS 'Result 2', CAST('Friday 20 July 2018' AS date) AS 'Result 3';

Risultato:

Conversion failed when converting date and/or time from character string.

E CAST() restituisce lo stesso errore.

Quindi se vi trovate ad avere errori con le altre due funzioni, provate invece PARSE().

Specificare la cultura

Un altro scenario in cui potreste preferire usare la funzione PARSE() è quando specificate la cultura/lingua in cui viene fornita la stringa. PARSE() ha un argomento opzionale che ti permette di specificare quale cultura usare. Se omesso, viene usata la lingua della sessione corrente.

Esempio dell’inclusione dell’argomento culture:

SELECT PARSE('07/01/2018' AS date USING 'en-US') AS 'Result 1', PARSE('07/01/2018' AS date USING 'de-DE') AS 'Result 2';

Risultato:

+------------+------------+| Result 1 | Result 2 ||------------+------------|| 2018-07-01 | 2018-01-07 |+------------+------------+

Una cultura alternativa

Nonostante il vantaggio di poter specificare la cultura con PARSE(), hai la possibilità di cambiare le impostazioni della lingua, il che significa che potresti ottenere lo stesso effetto usando CAST() o CONVERT().

Per esempio, usando SET LANGUAGE us_english prima della query cambierà le impostazioni della lingua corrente in us_english. Mentre questo non ti permette di specificare diverse culture all’interno della query (come nell’esempio precedente), influenza l’intera query (e qualsiasi query successiva).

Puoi anche cambiare le impostazioni del formato della data nello stesso modo. Per esempio, SET DATEFORMAT mdy.

Ecco un esempio di modifica delle impostazioni della lingua prima di eseguire una query con CAST() e CONVERT():

Tedesco:

SET LANGUAGE German;SELECT CONVERT(date, '07/01/2018') AS 'Convert';SELECT CAST('07/01/2018' AS date) AS 'Cast';

Risultato:

+------------+| Convert ||------------|| 2018-01-07 |+------------+Die Spracheneinstellung wurde in Deutsch geändert.+------------+| Cast ||------------|| 2018-01-07 |+------------+

us_english:

SET LANGUAGE us_english;SELECT CONVERT(date, '07/01/2018') AS 'Convert';SELECT CAST('07/01/2018' AS date) AS 'Cast';

Risultato:

+------------+| Convert ||------------|| 2018-07-01 |+------------+Changed language setting to us_english.+------------+| Cast ||------------|| 2018-07-01 |+------------+

Ricorda che quando fai questo, stai cambiando la lingua/ambiente di formato della data per la sessione. Non dimenticare di cambiarlo di nuovo!