Ghidul bazei de date

Poate că ați întâlnit funcțiile T-SQL PARSE(), CAST() și CONVERT() atunci când lucrați cu SQL Server și v-ați întrebat care este diferența. Toate cele trei funcții par să facă același lucru, dar există diferențe subtile între ele.

În acest articol îmi propun să prezint principalele diferențe dintre aceste funcții.

Comparare

Iată un tabel care prezintă principalele diferențe dintre funcțiile CONVERT(), CAST() și PARSE() din SQL Server:

	CONVERT()	CAST()	PARSE()
Definiție oficială	Converte o expresie de la un tip de date la altul.	Convertește o expresie de la un tip de date la altul.	Întoarce rezultatul unei expresii, tradus în tipul de date solicitat în SQL Server.
Valoare acceptată	Orice expresie validă.	Cealaltă expresie validă.	String.
Return Value	Al doilea argument, tradus în tipul de date solicitat, așa cum este furnizat de primul argument.	1-lea argument, tradus în tipul de date solicitat, așa cum este furnizat de al 2-lea argument.	1-lea argument, tradus în tipul de date solicitat, așa cum este furnizat de al 2-lea argument.
Conversii acceptate	Între două tipuri de date oarecare.	Între două tipuri de date oarecare.	Din șir de caractere în tipuri de date/timp și numere numai.
Aceptă argumentul de stil?	Da.	Nu.	Nu.
Aceptă argumentul culture?	Nu.	Nu.	Da.
Recherce .NET Framework?	Nu.	Nu.	Da.

Câteva alte puncte în plus față de tabelul de mai sus:

• Documentația Microsoft subliniază faptul că PARSE() nu va fi îndepărtat (deoarece depinde de prezența CLR). Remoting-ul unei funcții care necesită CLR ar provoca o eroare pe serverul de la distanță.
• Există unele valori cu care PARSE() se poate ocupa, dar CAST() și CONVERT() nu (de exemplu, șiruri de caractere care utilizează anumite formate de date).
• CAST() este inclus în standardul ANSI SQL-92.
• Cei care susțin că CAST() are performanțe mai bune decât celelalte două.
• Există o anumită supraîncărcare de performanță atunci când se analizează valori de tip șir de caractere. Prin urmare, PARSE() va rula de obicei mai lent decât celelalte două.

Mai jos sunt prezentate exemple de situații în care fiecare funcție ar fi cea mai potrivită.

Când să folosiți CAST()

Un argument bun ar putea fi făcut pentru a folosi CAST() pentru orice scenariu care nu este enumerat mai jos. După cum s-a menționat, CAST() face parte din standardul ANSI SQL încă din SQL-92, deci ar trebui să fie mai portabilă între diferite SGBD-uri (dacă aceasta este o cerință).

De asemenea, unii susțin că CAST() are o performanță mai bună decât celelalte două (aici este un articol interesant care compară performanța între toate cele trei funcții).

Cu toate acestea, există, de asemenea, motive valabile pentru care ați putea prefera (sau avea nevoie) să folosiți CONVERT() în locul lui CAST().

Când să folosiți CONVERT()

Funcția CONVERT() poate fi utilă atunci când trebuie să folosiți argumentul style pentru a specifica modul în care data trebuie formatată atunci când faceți conversia între o dată și un șir de caractere. Iată câteva exemple:

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';

Rezultat:

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

Puteți face acest lucru numai cu CONVERT() deoarece:

• CAST() nu suportă argumentul style; și
• PARSE() nu convertește dintr-o dată/ora într-o valoare de tip șir de caractere (de asemenea, nu suportă argumentul style)

Când să folosiți PARSE()

În ciuda diverselor dezavantaje ale acestei funcții (performanță, dependență de .NET, conversii limitate ale tipurilor de date), aceasta are și unele avantaje și există unele scenarii în care ar putea fi singura alegere. De exemplu, atunci când se furnizează o dată care include numele zilei săptămânii, cum ar fi vineri, 20 iulie 2018.

Când celelalte returnează o eroare

Iată exemple în care PARSE() este singura funcție dintre cele trei care poate converti cu succes valoarea fără a arunca o eroare.

În aceste exemple, încercăm să convertim diverse valori de tip șir de caractere într-un tip de date de tip dată. Cu toate acestea, valorile de tip șir pe care le furnizăm includ numele zilei săptămânii. Acest lucru cauzează probleme pentru CAST() și CONVERT(), dar PARSE() nu are nicio problemă.

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';

Rezultat:

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

Deci PARSE() nu are nicio problemă cu formatul datei pe care îl furnizăm.

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';

Rezultat:

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

Deci CONVERT() nu poate converti șirul de caractere atunci când acesta are un astfel de format.

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';

Rezultat:

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

Și CAST() returnează aceeași eroare.

Așa că, dacă vă treziți că primiți erori cu celelalte două funcții, încercați PARSE() în schimb.

Specificarea culturii

Un alt scenariu în care ați putea prefera să folosiți funcția PARSE() este atunci când specificați cultura/limba în care este furnizat șirul de caractere. PARSE() are un argument opțional care vă permite să specificați ce cultură să utilizați. Dacă este omisă, se utilizează limba sesiunii curente.

Exemplu de includere a argumentului 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';

Rezultat:

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

O alternativă de cultură

În ciuda avantajului de a putea specifica cultura cu PARSE(), aveți posibilitatea de a schimba setările de limbă, ceea ce înseamnă că ați putea obține același efect atunci când utilizați CAST() sau CONVERT().

De exemplu, utilizarea lui SET LANGUAGE us_english înainte de interogare va schimba setările curente ale limbii în us_english. Deși acest lucru nu vă permite să specificați culturi diferite în cadrul interogării (ca în exemplul de mai sus), afectează întreaga interogare (și orice interogare ulterioară).

De asemenea, puteți modifica setările privind formatul datei în același mod. De exemplu, SET DATEFORMAT mdy.

Iată un exemplu de modificare a setărilor de limbă înainte de a rula o interogare cu CAST() și CONVERT():

Germană:

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

Rezultat:

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

Rezultat:

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

Amintiți-vă că, atunci când faceți acest lucru, schimbați mediul de limbă/formatul datei pentru sesiune. Nu uitați să îl schimbați înapoi!

.