Database.Guide

Vielleicht sind Sie bei Ihrer Arbeit mit SQL Server schon auf die T-SQL-Funktionen PARSE(), CAST() und CONVERT() gestoßen und haben sich gefragt, worin der Unterschied besteht. Alle drei Funktionen scheinen das Gleiche zu tun, aber es gibt feine Unterschiede zwischen ihnen.

In diesem Artikel möchte ich die Hauptunterschiede zwischen diesen Funktionen erläutern.

Vergleich

Hier ist eine Tabelle, die die Hauptunterschiede zwischen den Funktionen CONVERT(), CAST() und PARSE() in SQL Server aufzeigt:

	CONVERT()	CAST()	PARSE()
Offizielle Definition	Konvertiert einen Ausdruck von einem Datentyp in einen anderen.	Konvertiert einen Ausdruck eines Datentyps in einen anderen.	Gibt das Ergebnis eines Ausdrucks zurück, der in den angeforderten Datentyp in SQL Server übersetzt wurde.
Akzeptierter Wert	Beliebiger gültiger Ausdruck.	Beliebiger gültiger Ausdruck.	String.
Rückgabewert	Zweites Argument, übersetzt in den angeforderten Datentyp, wie durch das erste Argument bereitgestellt.	1. Argument, übersetzt in den angeforderten Datentyp, wie vom 2. Argument bereitgestellt.	1. Argument, übersetzt in den angeforderten Datentyp, wie vom 2.
Unterstützte Konvertierungen	Zwischen zwei beliebigen Datentypen.	Zwischen zwei beliebigen Datentypen.	Nur von String zu Datum/Zeit und Zahlentypen.
Akzeptiert das Stilargument?	Ja.	Nein.	Nein.
Akzeptiert das Kultur Argument?	Nein.	Nein.	Ja.
Erfordert .NET Framework?	Nein.	Nein.	Ja.

Zusätzlich zur obigen Tabelle einige weitere Punkte:

• Die Microsoft-Dokumentation weist darauf hin, dass PARSE() nicht remoted wird (da es vom Vorhandensein der CLR abhängt). Das Remoten einer Funktion, für die die CLR erforderlich ist, würde auf dem entfernten Server zu einem Fehler führen.
• Es gibt einige Werte, mit denen PARSE() umgehen kann, CAST() und CONVERT() jedoch nicht (z. B. Zeichenketten mit bestimmten Datumsformaten).
• CAST() ist im ANSI SQL-92-Standard enthalten.
• Einige argumentieren, dass CAST() eine bessere Leistung als die anderen beiden hat.
• Es gibt einen gewissen Leistungs-Overhead beim Parsen von String-Werten. Daher läuft PARSE() in der Regel langsamer als die anderen beiden.

Nachfolgend finden Sie Beispiele für Situationen, in denen jede Funktion am besten geeignet ist.

Wann sollte CAST()

Ein gutes Argument für die Verwendung von CAST() könnte für jedes Szenario angeführt werden, das nicht unten aufgeführt ist. Wie bereits erwähnt, ist CAST() seit SQL-92 Teil des ANSI-SQL-Standards, so dass es zwischen verschiedenen DBMS portabler sein sollte (falls dies eine Anforderung ist).

Außerdem argumentieren einige, dass CAST() eine bessere Leistung hat als die anderen beiden (hier ist ein interessanter Artikel, der die Leistung aller drei Funktionen vergleicht).

Es gibt jedoch auch triftige Gründe, warum Sie CONVERT() gegenüber CAST() bevorzugen (oder benötigen).

Wann verwenden Sie CONVERT()

Die Funktion CONVERT() kann sich als nützlich erweisen, wenn Sie das Argument style verwenden müssen, um anzugeben, wie das Datum bei der Konvertierung zwischen einem Datum und einer Zeichenfolge formatiert werden soll. Hier einige Beispiele:

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

Ergebnis:

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

Sie können dies nur mit CONVERT() tun, weil:

• CAST() das Argument style nicht unterstützt; und
• PARSE() nicht von einem Datum/Zeitwert in einen String-Wert konvertiert (es unterstützt auch nicht das Argument style)

Wann PARSE()

Trotz der verschiedenen Nachteile dieser Funktion (Leistung, Abhängigkeit von .NET, eingeschränkte Datentypkonvertierungen), hat sie auch einige Vorteile, und es gibt einige Szenarien, in denen sie die einzige Wahl sein könnte. Zum Beispiel, wenn Sie ein Datum bereitstellen, das den Namen des Wochentags enthält, wie Freitag, 20. Juli 2018.

Wenn die anderen einen Fehler zurückgeben

Hier sind Beispiele, bei denen PARSE() die einzige Funktion der drei ist, die den Wert erfolgreich konvertieren kann, ohne einen Fehler auszulösen.

In diesen Beispielen versuchen wir, verschiedene String-Werte in einen Datentyp zu konvertieren. Die String-Werte, die wir bereitstellen, enthalten jedoch den Namen des Wochentags. Dies verursacht Probleme für CAST() und CONVERT(), aber PARSE() hat kein 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';

Ergebnis:

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

So hat PARSE() kein Problem mit dem Format des Datums, das wir bereitstellen.

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

Ergebnis:

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

So CONVERT() ist nicht in der Lage, die Zeichenfolge zu konvertieren, wenn sie ein solches Format hat.

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

Ergebnis:

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

Und CAST() gibt denselben Fehler zurück.

Wenn Sie also mit den beiden anderen Funktionen Fehler erhalten, versuchen Sie stattdessen PARSE().

Angabe der Kultur

Ein weiteres Szenario, in dem Sie die Funktion PARSE() vorziehen könnten, ist die Angabe der Kultur/Sprache, in der die Zeichenkette geliefert wird. PARSE() hat ein optionales Argument, mit dem Sie angeben können, welche Kultur verwendet werden soll. Wenn es weggelassen wird, wird die Sprache der aktuellen Sitzung verwendet.

Beispiel für die Angabe des Arguments 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';

Ergebnis:

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

Eine kulturelle Alternative

Trotz des Vorteils, die Kultur mit PARSE() angeben zu können, haben Sie die Möglichkeit, die Spracheinstellungen zu ändern, was bedeutet, dass Sie den gleichen Effekt erzielen können, wenn Sie CAST() oder CONVERT() verwenden.

Wenn Sie zum Beispiel SET LANGUAGE us_english vor der Abfrage verwenden, werden die aktuellen Spracheinstellungen auf us_englisch geändert. Damit können Sie zwar nicht verschiedene Kulturen innerhalb der Abfrage angeben (wie im obigen Beispiel), aber es wirkt sich auf die gesamte Abfrage (und alle nachfolgenden Abfragen) aus.

Auf dieselbe Weise können Sie auch die Einstellungen für das Datumsformat ändern. Zum Beispiel: SET DATEFORMAT mdy.

Hier ein Beispiel für die Änderung der Spracheinstellung vor der Ausführung einer Abfrage mit CAST() und CONVERT():

Deutsch:

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

Ergebnis:

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

Result:

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

Denken Sie daran, dass Sie damit die Sprach-/Datumsformatumgebung für die Sitzung ändern. Vergessen Sie nicht, sie wieder zu ändern!