Talán találkozott már a T-SQL PARSE(), CAST() és CONVERT() függvényekkel az SQL Serverrel való munka során, és elgondolkodott azon, hogy mi a különbség. Mindhárom függvény látszólag ugyanazt teszi, de vannak közöttük finom különbségek.
Ezzel a cikkel igyekszem felvázolni a függvények közötti főbb különbségeket.
Összehasonlítás
Itt egy táblázat, amely az SQL Server CONVERT(), CAST() és PARSE() függvények közötti főbb különbségeket vázolja fel:
| CONVERT() | CAST() | PARSE() | |
|---|---|---|---|
| Hivatalos definíció | Konvertálja az egyik adattípus kifejezését egy másik adattípusba. | Az egyik adattípusú kifejezést egy másik adattípussá konvertálja. | A kifejezés eredményét adja vissza, az SQL Server kért adattípusra lefordítva. |
| Akceptált érték | Minden érvényes kifejezés. | Minden érvényes kifejezés. | String. |
| Return Value | 2. argumentum, az 1. argumentum által megadott kért adattípusra lefordítva. | 1. argumentum, a 2. argumentum által megadott kért adattípusra lefordítva. | 1. argumentum, a 2. argumentum által megadott kért adattípusra lefordítva. |
| Támogatott konverziók | Minden két adattípus között. | Minden két adattípus között. | Kizárólag stringből dátum/idő és szám típusba. |
| A stílus argumentumot elfogadja? | Igen. | Nem. | Nem. |
| Akceptálja a culture argumentumot? | Nem. | Nem. | Igen. |
| Követeli a .NET keretrendszer használatát? | Nem. | Nem. | Igen. |
Néhány egyéb pont a fenti táblázaton kívül:
- A Microsoft dokumentációja rámutat arra, hogy a
PARSE()nem lesz remoted (mivel a CLR meglététől függ). A CLR-t igénylő függvény remotingja hibát okozna a távoli kiszolgálón. - Vannak olyan értékek, amelyeket a
PARSE()tud kezelni, de aCAST()és aCONVERT()nem (például bizonyos dátumformátumokat használó karakterláncok). - Az
CAST()szerepel az ANSI SQL-92 szabványban. - Egyes vélemények szerint az
CAST()jobb teljesítményt nyújt, mint a másik kettő. - A string értékek elemzése bizonyos teljesítménytöbbletet jelent. Ezért a
PARSE()jellemzően lassabban fog futni, mint a másik kettő.
Az alábbiakban példákat találunk olyan helyzetekre, amikor az egyes függvények a legmegfelelőbbek lennének.
Mikor használjuk a CAST()
Az CAST() használata mellett jó érveket lehetne felhozni minden olyan forgatókönyv esetében, amely nincs az alábbiakban felsorolva. Mint említettük, az CAST() az SQL-92 óta része az ANSI SQL szabványnak, így a különböző DBMS-ek között hordozhatóbbnak kell lennie (ha ez követelmény).
Egyes vélemények szerint az CAST() jobb teljesítményű, mint a másik kettő (itt egy érdekes cikk, amely összehasonlítja a három függvény teljesítményét).
Mindamellett vannak olyan jogos okok is, amelyek miatt a CONVERT() használatát előnyben részesíthetjük (vagy szükségünk lehet rá) a CAST() helyett.
Mikor használjuk a CONVERT()
A CONVERT() függvény akkor jöhet jól, ha a style argumentummal kell megadni, hogyan kell a dátumot formázni a dátum és egy karakterlánc közötti konverzió során. Íme néhány példa:
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';
Eredmény:
+---------------------+------------+------------+------------+| 100 | 101 | 102 | 103 ||---------------------+------------+------------+------------|| Jun 7 2018 2:35AM | 06/07/2018 | 2018.06.07 | 07/06/2018 |+---------------------+------------+------------+------------+
Azt csak a CONVERT() segítségével teheti meg, mert:
-
CAST()nem támogatja astyleargumentumot; és -
PARSE()nem konvertál dátum/időből string értékké (szintén nem támogatja astyleargumentumot)
Mikor használjuk a PARSE()
A függvény különböző hátrányai ellenére (teljesítmény, függőség a .NET, korlátozott adattípus-konverziók), van néhány előnye is, és vannak olyan forgatókönyvek, amikor ez lehet az egyetlen választás. Például, ha olyan dátumot adunk meg, amely tartalmazza a hétköznap nevét, például 2018. július 20., péntek.
Ha a többi hibát ad vissza
Az alábbi példákban a PARSE() az egyetlen olyan függvény a három közül, amely sikeresen konvertálja az értéket anélkül, hogy hibát dobna.
A példákban különböző karakterláncértékeket próbálunk dátum adattípussá konvertálni. Az általunk megadott karakterláncértékek azonban tartalmazzák a hétköznap nevét. Ez problémát okoz a CAST() és a CONVERT() esetében, de a PARSE()-nek nincs problémája.
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';
Eredmény:
+------------+------------+------------+| Result 1 | Result 2 | Result 3 ||------------+------------+------------|| 2018-07-20 | 2018-07-20 | 2018-07-20 |+------------+------------+------------+
Az általunk megadott dátum formátumával tehát a PARSE()-nek nincs problémája.
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';
Eredmény:
Conversion failed when converting date and/or time from character string.
Az CONVERT() tehát nem tudja átalakítani a karakterláncot, ha az ilyen formátumú.
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';
Eredmény:
Conversion failed when converting date and/or time from character string.
Az CAST() pedig ugyanazt a hibát adja vissza.
Ha tehát a másik két függvénynél is hibát kapsz, próbáld meg a PARSE()-t helyette.
A kultúra megadása
Egy másik forgatókönyv, amikor inkább a PARSE() függvényt használhatod, az a kultúra/nyelv megadása, amelyen a karakterláncot megadod. A PARSE() funkciónak van egy opcionális argumentuma, amely lehetővé teszi, hogy megadjuk, milyen kultúrát használjunk. Ha kihagyja, akkor az aktuális munkamenet nyelve kerül használatba.
Példa a culture argumentum megadására:
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';
Eredmény:
+------------+------------+| Result 1 | Result 2 ||------------+------------|| 2018-07-01 | 2018-01-07 |+------------+------------+
A kultúra alternatívája
Az előnye ellenére, hogy a PARSE() segítségével megadhatja a kultúrát, lehetősége van a nyelvi beállítások megváltoztatására, ami azt jelenti, hogy ugyanezt a hatást elérheti a CAST() vagy CONVERT() használatával.
A lekérdezés előtt a SET LANGUAGE us_english használatával például az aktuális nyelvi beállítások us_english-re változnak. Ez ugyan nem teszi lehetővé különböző kultúrák megadását a lekérdezésen belül (mint a fenti példában), de hatással van az egész lekérdezésre (és minden későbbi lekérdezésre).
A dátumformátum beállításait is ugyanígy módosíthatja. Például SET DATEFORMAT mdy.
Itt egy példa a nyelvi beállítás megváltoztatására a CAST() és CONVERT() lekérdezés futtatása előtt:
Német:
SET LANGUAGE German;SELECT CONVERT(date, '07/01/2018') AS 'Convert';SELECT CAST('07/01/2018' AS date) AS 'Cast';
Eredmény:
+------------+| 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';
Eredmény:
+------------+| Convert ||------------|| 2018-07-01 |+------------+Changed language setting to us_english.+------------+| Cast ||------------|| 2018-07-01 |+------------+
Ne feledje, hogy amikor ezt teszi, megváltoztatja a munkamenet nyelvi/időzítési formátumának környezetét. Ne felejtsd el visszaállítani!