PARSE() vs CAST() vs CONVERT() in SQL Server:qual è la differenza?

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

In questo articolo miro a delineare le principali differenze tra queste funzioni.

Confronto

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

Alcuni altri punti oltre alla tabella sopra:

• La documentazione Microsoft sottolinea che PARSE() non verrà remotato (poiché dipende dalla presenza del CLR). Remotare una funzione che richiede il CLR causerebbe un errore sul server remoto.
• Ci sono alcuni valori che PARSE() può gestire ma CAST() e CONVERT() impossibile (ad esempio, stringhe che utilizzano determinati formati di data).
• CAST() è incluso nello standard ANSI SQL-92.
• Alcuni sostengono che CAST() ha prestazioni migliori rispetto agli altri due.
• C'è un certo sovraccarico di prestazioni durante l'analisi dei valori di stringa. Pertanto, PARSE() in genere funzionerà più lentamente degli altri due.

Di seguito sono riportati esempi di situazioni in cui ciascuna funzione sarebbe la più adatta.

Quando usare CAST()

Potrebbe essere un buon argomento per l'utilizzo di CAST() per qualsiasi scenario non elencato di seguito. Come accennato, CAST() fa parte dello standard ANSI SQL da SQL-92, quindi dovrebbe essere più portabile tra diversi DBMS (se necessario).

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

Tuttavia, ci sono anche validi motivi per cui potresti preferire (o aver bisogno) di utilizzare CONVERT() su CAST() .

Quando usare CONVERT()

Il CONVERT() la funzione può tornare utile quando devi usare lo style argomento per specificare come deve essere formattata la data 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 |
+---------------------+------------+------------+------------+

Puoi farlo solo con CONVERT() perché:

• CAST() non supporta lo style discussione; e
• PARSE() non converte da una data/ora a un valore stringa (inoltre non supporta lo style argomento)

Quando usare PARSE()

Nonostante i vari svantaggi di questa funzione (prestazioni, dipendenza da .NET, conversioni di tipi di dati limitate), presenta anche alcuni vantaggi e ci sono alcuni scenari in cui potrebbe essere la tua unica scelta. Ad esempio, quando fornisci una data che includa il nome del giorno della settimana, ad esempio venerdì 20 luglio 2018 .

Quando gli altri restituiscono un errore

Ecco alcuni esempi in cui PARSE() è l'unica funzione delle tre che può convertire correttamente il valore senza generare errori.

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

ANALISI()

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.

CONVERTI()

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 un 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 ti ritrovi a ricevere errori con le altre due funzioni, prova PARSE() invece.

Specificare la cultura

Un altro scenario in cui potresti preferire l'uso di PARSE() La funzione è quando si specifica la cultura/lingua in cui è fornita la stringa. PARSE() dispone di un argomento facoltativo che consente di specificare le impostazioni cultura da usare. Se omesso, viene utilizzata la lingua della sessione corrente.

Esempio di inclusione della culture argomento:

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 |
+------------+------------+

Un'alternativa culturale

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

Ad esempio, utilizzando SET LANGUAGE us_english prima della query cambierà le impostazioni della lingua corrente in us_english . Sebbene ciò non ti permetta di specificare culture diverse all'interno della query (come nell'esempio sopra), influisce sull'intera query (e su eventuali query successive).

Allo stesso modo puoi anche modificare le impostazioni del formato della data. Ad esempio, SET DATEFORMAT mdy .

Ecco un esempio di modifica dell'impostazione 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, quando lo fai, stai cambiando l'ambiente del formato lingua/data per la sessione. Non dimenticare di cambiarlo di nuovo!