PARSE() vs CAST() vs CONVERT() dans SQL Server :Quelle est la différence ?

Peut-être avez-vous rencontré le T-SQL PARSE() , CAST() , et CONVERT() fonctionne lorsque vous travaillez avec SQL Server et vous vous demandez quelle est la différence. Les trois fonctions semblent faire la même chose, mais il existe des différences subtiles entre elles.

Dans cet article, je vise à décrire les principales différences entre ces fonctions.

Comparaison

Voici un tableau qui décrit les principales différences entre CONVERT() , CAST() , et PARSE() fonctions dans SQL Server :

Quelques autres points en plus du tableau ci-dessus :

• La documentation Microsoft indique que PARSE() ne sera pas déporté (car cela dépend de la présence du CLR). L'accès à distance à une fonction nécessitant le CLR entraînerait une erreur sur le serveur distant.
• Certaines valeurs sont PARSE() peut gérer mais CAST() et CONVERT() ne peut pas (par exemple, les chaînes utilisant certains formats de date).
• CAST() est inclus dans la norme ANSI SQL-92.
• Certains prétendent que CAST() a de meilleures performances que les deux autres.
• Il y a une certaine surcharge de performances lors de l'analyse des valeurs de chaîne. Par conséquent, PARSE() fonctionnera généralement plus lentement que les deux autres.

Vous trouverez ci-dessous des exemples de situations où chaque fonction serait la plus appropriée.

Quand utiliser CAST()

Un bon argument pourrait être avancé pour utiliser CAST() pour tout scénario qui n'est pas répertorié ci-dessous. Comme mentionné, CAST() fait partie de la norme ANSI SQL depuis SQL-92, il devrait donc être plus portable entre différents SGBD (si c'est une exigence).

De plus, certains soutiennent que CAST() a de meilleures performances que les deux autres (voici un article intéressant qui compare les performances entre les trois fonctions).

Cependant, il existe également des raisons valables pour lesquelles vous pourriez préférer (ou avoir besoin) d'utiliser CONVERT() sur CAST() .

Quand utiliser CONVERT()

Le CONVERT() la fonction peut être utile lorsque vous devez utiliser le style argument pour spécifier comment la date doit être formatée lors de la conversion entre une date et une chaîne. Voici quelques exemples :

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

Résultat :

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

Vous ne pouvez le faire qu'avec CONVERT() parce que :

• CAST() ne prend pas en charge le style argument; et
• PARSE() ne convertit pas une date/heure en une valeur de chaîne (il ne prend pas non plus en charge le style arguments)

Quand utiliser PARSE()

Malgré les divers inconvénients de cette fonction (performances, dépendance à .NET, conversions de types de données limitées), elle présente également certains avantages, et il existe certains scénarios où elle pourrait être votre seul choix. Par exemple, lorsque vous fournissez une date qui inclut le nom du jour de la semaine, comme Vendredi 20 juillet 2018 .

Lorsque les autres renvoient une erreur

Voici des exemples où PARSE() est la seule fonction des trois qui peut convertir avec succès la valeur sans générer d'erreur.

Dans ces exemples, nous essayons de convertir diverses valeurs de chaîne en une date Type de données. Cependant, les valeurs de chaîne que nous fournissons incluent le nom du jour de la semaine. Cela cause des problèmes pour CAST() et CONVERT() , mais PARSE() n'a aucun problème.

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

Résultat :

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

Donc PARSE() n'a aucun problème avec le format de la date que nous fournissons.

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

Résultat :

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

Donc CONVERT() est incapable de convertir la chaîne lorsqu'elle est dans un tel 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';

Résultat :

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

Et CAST() renvoie la même erreur.

Donc, si vous rencontrez des erreurs avec les deux autres fonctions, essayez PARSE() à la place.

Spécifier la culture

Un autre scénario où vous préférerez peut-être utiliser le PARSE() La fonction est lors de la spécification de la culture/langue dans laquelle la chaîne est fournie. PARSE() a un argument facultatif qui vous permet de spécifier la culture à utiliser. Si omis, la langue de la session en cours est utilisée.

Exemple d'inclusion de la 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';

Résultat :

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

Une alternative culturelle

Malgré l'avantage de pouvoir spécifier la culture avec PARSE() , vous avez la possibilité de modifier les paramètres de langue, ce qui signifie que vous pouvez obtenir le même effet en utilisant CAST() ou CONVERT() .

Par exemple, en utilisant SET LANGUAGE us_english avant la requête changera les paramètres de langue actuels en us_english . Bien que cela ne vous permette pas de spécifier différentes cultures dans la requête (comme dans l'exemple ci-dessus), cela affecte l'ensemble de la requête (et toutes les requêtes suivantes).

Vous pouvez également modifier les paramètres de format de date de la même manière. Par exemple, SET DATEFORMAT mdy .

Voici un exemple de modification du paramètre de langue avant d'exécuter une requête avec CAST() et CONVERT() :

Allemand :

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

Résultat :

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

Résultat :

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

N'oubliez pas que lorsque vous faites cela, vous modifiez l'environnement de format de langue/date pour la session. N'oubliez pas de le remettre en place !