PARSE() vs CAST() vs CONVERT() in SQL Server:wat is het verschil?

Misschien bent u de T-SQL PARSE() tegengekomen , CAST() , en CONVERT() functioneert bij het werken met SQL Server en vroeg zich af wat het verschil is. Alle drie de functies lijken hetzelfde te doen, maar er zijn subtiele verschillen tussen hen.

In dit artikel wil ik de belangrijkste verschillen tussen deze functies schetsen.

Vergelijking

Hier is een tabel met de belangrijkste verschillen tussen de CONVERT() , CAST() , en PARSE() functies in SQL Server:

Enkele andere punten naast de bovenstaande tabel:

• De Microsoft-documentatie wijst erop dat PARSE() niet op afstand (aangezien dit afhangt van de aanwezigheid van de CLR). Het op afstand plaatsen van een functie die de CLR vereist, zou een fout veroorzaken op de externe server.
• Er zijn enkele waarden die PARSE() kan omgaan met maar CAST() en CONVERT() kan niet (bijvoorbeeld tekenreeksen die bepaalde datumnotaties gebruiken).
• CAST() is opgenomen in de ANSI SQL-92-standaard.
• Sommigen beweren dat CAST() presteert beter dan de andere twee.
• Er is een bepaalde prestatieoverhead bij het ontleden van tekenreekswaarden. Daarom, PARSE() zullen doorgaans langzamer werken dan de andere twee.

Hieronder staan ​​voorbeelden van situaties waarin elke functie het meest geschikt zou zijn.

Wanneer CAST() gebruiken

Er zou een goed argument kunnen worden aangevoerd voor het gebruik van CAST() voor elk scenario dat hieronder niet wordt vermeld. Zoals vermeld, CAST() maakt sinds SQL-92 deel uit van de ANSI SQL-standaard, dus het zou beter overdraagbaar moeten zijn tussen verschillende DBMS'en (als dat een vereiste is).

Sommigen beweren ook dat CAST() heeft betere prestaties dan de andere twee (hier is een interessant artikel dat de prestaties van alle drie de functies vergelijkt).

Er zijn echter ook geldige redenen waarom u er de voorkeur aan geeft (of nodig heeft) om CONVERT() te gebruiken. via CAST() .

Wanneer CONVERT() gebruiken

De CONVERT() functie kan van pas komen wanneer u de style . moet gebruiken argument om aan te geven hoe de datum moet worden opgemaakt bij het converteren tussen een datum en een tekenreeks. Hier zijn enkele voorbeelden:

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

Resultaat:

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

Je kunt dit alleen doen met CONVERT() omdat:

• CAST() ondersteunt de style . niet argument; en
• PARSE() converteert niet van een datum/tijd naar een tekenreekswaarde (het ondersteunt ook niet de style argument)

Wanneer PARSE() gebruiken

Ondanks de verschillende nadelen van deze functie (prestaties, afhankelijkheid van .NET, beperkte gegevenstypeconversies), heeft deze ook enkele voordelen, en er zijn enkele scenario's waarin dit uw enige keuze zou kunnen zijn. Als u bijvoorbeeld een datum opgeeft die de naam van de weekdag bevat, zoals vrijdag 20 juli 2018 .

Als de anderen een fout retourneren

Hier zijn voorbeelden waar PARSE() is de enige functie van de drie die de waarde met succes kan converteren zonder een fout te veroorzaken.

In deze voorbeelden proberen we verschillende tekenreekswaarden om te zetten naar een datum data type. De tekenreekswaarden die we leveren, bevatten echter de naam van de weekdag. Dit veroorzaakt problemen voor CAST() en CONVERT() , maar PARSE() heeft geen probleem.

PASEREN()

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

Resultaat:

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

Dus PARSE() heeft geen probleem met het formaat van de datum die we verstrekken.

CONVERTEREN()

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

Resultaat:

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

Dus CONVERT() kan de string niet converteren als deze in een dergelijk formaat is.

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

Resultaat:

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

En CAST() geeft dezelfde fout terug.

Dus als je merkt dat je fouten krijgt met de andere twee functies, probeer dan PARSE() in plaats daarvan.

De cultuur specificeren

Een ander scenario waarin u misschien liever de PARSE() . gebruikt functie is bij het specificeren van de cultuur/taal waarin de string wordt geleverd. PARSE() heeft een optioneel argument waarmee u kunt specificeren welke cultuur u wilt gebruiken. Indien weggelaten, wordt de taal van de huidige sessie gebruikt.

Voorbeeld van het opnemen van de culture argument:

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

Resultaat:

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

Een cultuuralternatief

Ondanks het voordeel dat je de cultuur kunt specificeren met PARSE() , hebt u de mogelijkheid om de taalinstellingen te wijzigen, wat betekent dat u hetzelfde effect kunt bereiken bij het gebruik van CAST() of CONVERT() .

Gebruik bijvoorbeeld SET LANGUAGE us_english voorafgaand aan de zoekopdracht worden de huidige taalinstellingen gewijzigd in us_english . Hoewel u hierdoor geen verschillende culturen binnen de zoekopdracht kunt specificeren (zoals in het bovenstaande voorbeeld), heeft dit wel invloed op de hele zoekopdracht (en eventuele volgende zoekopdrachten).

U kunt op dezelfde manier ook de instellingen voor de datumnotatie wijzigen. Bijvoorbeeld SET DATEFORMAT mdy .

Hier is een voorbeeld van het wijzigen van de taalinstelling voordat u een zoekopdracht uitvoert met CAST() en CONVERT() :

Duits:

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

Resultaat:

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

Resultaat:

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

Onthoud dat wanneer u dit doet, u de taal/datumnotatieomgeving voor de sessie wijzigt. Vergeet niet om het terug te veranderen!