Database
 sql >> Base de données >  >> RDS >> Database

4 méthodes de conversion de données SQL prêtes à l'emploi et cas d'utilisation

Tout d'abord, vous ne pouvez pas vous en passer, n'est-ce pas ?

Les conversions de données SQL ou, plus précisément, les conversions de types de données sont une partie essentielle du travail de programmation régulier d'un développeur de base de données ou d'un administrateur de base de données.

Et si votre patron signait un contrat avec une autre entreprise pour lui fournir un fichier au format texte provenant de votre base de données SQL Server ?

Cela ressemble à un défi passionnant !

Mais vous avez découvert que vous deviez gérer une date en une chaîne, un nombre en une chaîne et un tas d'autres conversions de données SQL. Êtes-vous toujours prêt à relever le défi ?

Pas sans votre arsenal d'astuces de conversion de données !

Qu'est-ce qui est disponible prêt à l'emploi ?

Lorsque j'ai commencé la programmation T-SQL, la première chose que j'ai vue qui correspondait à l'objectif de la conversion était le CONVERT () fonction.

D'ailleurs, le mot "convertir" est là, non ?

Bien que cela puisse être vrai, ce n'est qu'une des 4 façons d'effectuer ce travail. Et je l'utilisais pour presque TOUTE ma conversion de données SQL. Je suis content d'avoir dépassé ça. Parce que j'ai appris que les 4 méthodes ont leur propre place dans votre code.

Avant d'aborder le sujet de l'article, permettez-moi de vous présenter les 4 méthodes prêtes à l'emploi pour effectuer la conversion de données SQL :

  • CAST ()
  • CONVERTIR ()
  • ANALYSE ()
  • TRY_CAST (), TRY_CONVERT (), TRY_PARSE ()

Chacune des sections ci-dessous :

  • Expliquez de quoi il s'agit
  • Vous dire quand l'utiliser (cas d'utilisation)
  • Présenter ses limites
  • Donnez des exemples et expliquez-le

Tout ce qui est présenté dans cet article est en anglais clair et simple autant que possible. Lorsque vous aurez fini de lire l'intégralité de l'article, vous saurez quelle méthode est appropriée pour une situation donnée.

Alors, sans plus tarder, plongeons dedans.

1. Conversion de données SQL à l'aide de CAST()

Bien que toutes les méthodes que vous verrez puissent convertir des types de données, votre premier choix de conversion devrait certainement être CAST ().

Voici les raisons :

  • C'est la fonction de conversion la plus rapide de toutes. Nous essaierons de le prouver plus tard dans cet article.
  • Il est inclus dans les normes de spécification du langage SQL-92. Ainsi, lorsque vous avez besoin de transférer votre code vers d'autres produits SQL, comme MySQL, la fonction est également disponible.

Voici une syntaxe très simple pour CAST ():

CAST( <expression> AS <data_type>[(length)] )

Examinons d'abord la syntaxe :

  • <expression> est une expression valide qui donne une valeur qui peut être convertie dans le type de données cible.
  • <type_données> est le type de données cible.
  • longueur est facultatif et dépend de la taille des données.

Quand l'utiliser

Si la seule chose dont vous avez besoin est de convertir une valeur en un autre type de données, alors CAST () est exactement ce dont vous avez besoin.

Limites

Du côté négatif, CAST () ne peut pas vous donner une sortie formatée prête à l'emploi comme une valeur de date et d'heure formatée.

Exemples

A. Convertir une chaîne en date : 

SELECT CAST('09/11/2004 4:30PM' as datetime2)

Et l'exécution de l'instruction ci-dessus donnera :

B. Convertir un nombre en chaîne : 

SELECT CAST(10.003458802 as varchar(max))

Et le résultat de la conversion ci-dessus est :

Maintenant, si vous avez besoin d'autre chose comme formater les données converties, la méthode suivante peut vous aider.

2. Conversion de données SQL à l'aide de CONVERT()

La prochaine option de conversion de données consiste à utiliser CONVERT (). Comme je l'ai déjà dit, c'est celui que j'utilisais le plus dans les premiers jours.

Voici la syntaxe :

CONVERT( <data_type>[(length)], <expression> [, <style>])

À partir de la syntaxe ci-dessus, notez que le style <> le paramètre est facultatif. Et à moins que vous ne le fournissiez, la fonction sera similaire à CAST ().

C'est là que ma confusion a commencé quand j'étais nouveau sur SQL.

Quand l'utiliser

Si vous convertissez les données avec un format instantané, alors CONVERT () est votre ami. Ce qui signifie que vous traitez le style <> paramètre correctement.

Limites

  • CAST () est plus rapide que CONVERT (), donc si vous avez seulement besoin de convertir les données, utilisez CAST (). Si la sortie doit être formatée, utilisez CONVERT ().
  • CONVERTIR () n'est pas une norme SQL-92, donc si vous avez besoin de le porter vers un autre SGBDR, évitez de l'utiliser.

Exemples

A. Convertir une date en format chaîne aaaammjj

Dans l'exemple suivant, j'utiliserai l'exemple de base de données AdventureWorks et transformez la [StartDate ] colonne à aaaammjj :

USE AdventureWorks
GO
SELECT
[BillOfMaterialsID]
,CONVERT(varchar(10), [StartDate],112) as StartDate
FROM [Production].BillOfMaterials]
GO

Notez que le style 112 est utilisé pour formater les dates en aaaammjj .

B. Convertissez un nombre en une chaîne avec des virgules tous les 3 chiffres à gauche de la virgule décimale.

De même, l'exemple suivant illustrera le AdventureWorks exemple de base de données, et nous formaterons le nombre avec des virgules et avec 2 décimales.

USE AdventureWorks
GO
SELECT
[TransactionID]
,[ProductID]
,CONVERT(varchar(10),[TransactionDate] ,112) as StartDate
,[Quantity]
,CONVERT(varchar(10),[ActualCost],1) as ActualCost
FROM [Production].TransactionHistory
GO

Notez que le format 1 est utilisé pour [ActualCost ]. Et merci à CONVERT (), nous pouvons formater ces colonnes en un instant.

Cependant, que se passe-t-il si vous devez convertir une expression de date plus longue ? Va CONVERTIR () travailler dans ce cas? Lisez la suite pour en savoir plus sur la méthode suivante.

3. Conversion de données SQL à l'aide de PARSE()

La prochaine méthode que nous allons considérer est PARSE ().

Vérifiez la syntaxe :

PARSE( <string value> AS <datatype> [USING <culture>])

Quand l'utiliser

  • Pour convertir des chaînes en dates ou en nombres à l'aide d'une culture spécifique.
  • Lorsque la chaîne ne peut pas être convertie en date ou en nombre à l'aide de CAST () ou CONVERTIR (). Voir les exemples pour plus d'informations.

Limites

  • La conversion n'est possible que pour les chaînes en dates et les chaînes en nombres
  • Repose sur la présence de .Net Framework Common Language Runtime (CLR) sur le serveur.
  • N'est pas inclus dans les spécifications standard SQL-92, donc le portage vers d'autres RDBMS est un problème.
  • A une surcharge de performances lorsqu'il s'agit d'analyser la chaîne.

Exemples

A. Conversion d'une longue chaîne de date 

SELECT PARSE('Monday, June 8, 2020' as datetime USING 'en-US')

L'exemple ci-dessus est une longue chaîne de date à convertir en datetime valeur en utilisant la culture anglaise américaine. Et c'est là que PARSE () fera de son mieux.

En effet, le code ci-dessus échouera si vous utilisez CAST () ou CONVERTIR ().

B. Conversion d'une valeur monétaire avec un symbole monétaire 

SELECT PARSE('€1024,01' as money using 'de-DE')

Maintenant, essayez de faire la conversion en utilisant CAST () et CONVERTIR ()

SELECT CONVERT(money,'€1024,01')
SELECT CAST('€1024,01' as money)

L'instruction ne générera pas d'erreurs, mais jetez un œil à ce résultat inattendu :

Par conséquent, la valeur a été convertie en 102401.00 au lieu de 1024.01.

Jusqu'à présent, nous avons découvert que les 3 premières méthodes sont sujettes à des erreurs à moins que vous ne les vérifiiez. Néanmoins, la 4ème méthode peut être votre solution au résultat erroné.

4. Conversion de données SQL à l'aide de TRY_CAST(), TRY_CONVERT() ou TRY_PARSE()

Enfin, la dernière méthode de conversion de données SQL utilise une variante des 3 premières mais avec un préfixe de TRY_.

Mais quand même, quelle est la différence ?

Ils ont les mêmes paramètres que les 3 précédents sans le préfixe TRY_. Mais la différence est qu'ils renvoient NULL si la valeur ne peut pas être convertie. Maintenant, si la valeur ne peut pas être convertie explicitement par l'un des 3, une erreur se produit. Voir les exemples ci-dessous pour une meilleure compréhension.

Quand l'utiliser

Vous pouvez utiliser n'importe lequel des 3 avec des instructions conditionnelles comme CASE QUAND ou IIF pour tester les erreurs.

Limites

Les 3 d'entre eux ont les mêmes limitations que ceux sans le préfixe TRY_, sauf pour les valeurs qui ne peuvent pas être converties.

Exemples

A. Utilisez TRY_CAST() pour tester si la conversion réussira en utilisant IIF : 

SELECT IIF(TRY_CAST('111b' AS real) IS NULL, 'Cast failed', 'Cast succeeded') AS Result

Le code ci-dessus renverra "Cast Failed" car "111b" ne peut pas être converti en réel . Supprimez le « b » de la valeur, et il renverra « Diffusion réussie ».

B. Utilisation de TRY_CONVERT() sur des dates avec un format spécifique 

SET DATEFORMAT dmy;
SELECT TRY_CONVERT(datetime2, '12/31/2010') AS Result

Cela renverra NULL car le format utilise dmy ou jour-mois-année. Et l'expression d'entrée pour TRY_CONVERT () est au format mdy ou mois-jour-année. L'erreur a été déclenchée car la valeur du mois est 31.

C. Utilisation de TRY_PARSE() qui générera une erreur d'exécution 

SELECT
CASE WHEN TRY_PARSE('10/21/2133' AS smalldatetime USING 'en-US') IS NULL
    THEN 'True'
    ELSE 'False'
END AS Result

Ce code générera une erreur d'exécution comme indiqué ci-dessous :

C'est tout pour les 4 méthodes prêtes à l'emploi dans la conversion de données SQL. Mais il y a plus à venir.

Qu'en est-il de la conversion de données SQL à l'aide de la conversion implicite ?


Considérons maintenant la conversion implicite. C'est une méthode silencieuse.

Pourquoi silencieux ?

Parce que vous le faites peut-être déjà, mais vous ne le savez pas. Ou du moins, vous savez que cela se produit, mais vous l'ignorez.

En d'autres termes, c'est le type de conversion que SQL effectue automatiquement sans aucune fonction.

Laissez-moi vous donner un exemple :

DECLARE @char CHAR(25)
DECLARE @varchar VARCHAR(25)
DECLARE @nvarchar NVARCHAR(25)
DECLARE @nchar NCHAR(25)
 
SET @char = 'Live long and prosper'
SET @varchar = @char
SET @nvarchar = @varchar
SET @nchar = @nvarchar
 
SELECT @char AS [char], @varchar AS [varchar], @nvarchar AS [nvarchar], @nchar AS [nchar]

Le code ci-dessus sera exécuté avec succès. Essayez-le vous-même et vous obtiendrez un résultat similaire à celui ci-dessous :

Essayons ceci avec des dates :

DECLARE @datetime datetime
DECLARE @smalldatetime smalldatetime
DECLARE @datetime2 datetime2

SET @datetime = '12/31/2050 14:34'
SET @smalldatetime = @datetime
SET @datetime2 = @smalldatetime

SELECT @datetime as [datetime], @smalldatetime as [smalldatetime], @datetime2 as [datetime2]

Comme prévu, cela donnera un résultat réussi :

Essayons cette fois avec des chiffres :

DECLARE @int int
DECLARE @real real
DECLARE @decimal decimal
DECLARE @float float

SET @int = 1701
SET @real = @int
SET @decimal = @real
SET @float = @decimal

SELECT @int as [int], @real as [real], @decimal as [decimal], @float as [float]

Toujours un succès, non ?

Jusqu'à présent, nous avons utilisé des valeurs simples qui conviendront à un type de données assez similaire. Passons au niveau suivant :des nombres aux chaînes.

DECLARE @number int
DECLARE @string varchar(5)

SET @number = 1701
SET @string = @number

SELECT @number as [number], @string as [string]

Cela sera converti avec succès comme vous pouvez le voir dans le résultat ci-dessous :

Il existe de nombreux autres cas où SQL Server essaiera de « deviner » comment convertir les données. Comme vous pouvez le voir dans cette référence, il existe de nombreuses instances par rapport à celles qui nécessitent une conversion explicite.

Étant donné que SQL Server le permet, cela signifie-t-il que vous pouvez librement autoriser cela dans tout votre code ?

Mises en garde concernant la conversion implicite

D'une part, cela peut être pratique. Mais une fois les limites de chaque type de données atteintes, vous vous rendrez compte que la conversion implicite est un peu dangereuse si elle n'est pas cochée.

Prenons un exemple ci-dessous :

DECLARE @char char(25)
DECLARE @varchar varchar(25)
DECLARE @nvarchar nvarchar(25)
DECLARE @nchar nchar(25)

SET @nvarchar = N'I ❤ U!'
SET @nchar = @nvarchar 
SET @char = @nchar
SET @varchar = @nchar

SELECT @char as [char], @varchar as [varchar], @nvarchar as [nvarchar], @nchar as [nchar]

Avez-vous vu la valeur emoji ? Cela comptera comme une valeur unicode.

Bien que toutes les instructions ci-dessus s'exécutent avec succès, les variables avec des types non Unicode comme varchar et char aura des résultats inattendus. Voir le résultat ci-dessous :

Néanmoins, ce n'est pas le seul problème. Des erreurs apparaîtront lorsque la valeur devient hors plage. Prenons un exemple avec des dates :

DECLARE @datetime datetime
DECLARE @smalldatetime smalldatetime
DECLARE @datetime2 datetime2

SET @datetime = '12/31/2374 14:34'
SET @smalldatetime = @datetime
SET @datetime2 = @smalldatetime

SELECT @datetime as [datetime], @smalldatetime as [smalldatetime], @datetime2 as [datetime2]

L'attribution de la datetime valeur à smalldatetime la variable déclenchera l'erreur comme vous pouvez le voir ci-dessous :

Mais il y a une autre mise en garde, dont vous devez également être conscient lorsque vous traitez avec une conversion implicite :la surcharge de performances. Vu qu'il s'agit d'un sujet brûlant, il mérite d'avoir une section distincte.

Implications sur les performances des différentes méthodes de conversion de données SQL

Croyez-le ou non, différentes méthodes de conversion de données SQL auront des performances différentes dans des situations réelles. Et vous devriez au moins en être conscient afin d'éviter les problèmes de performances.

Comment CAST(), CONVERT() et PARSE() fonctionnent

Examinons d'abord comment CAST (), CONVERTIR (), et PARSE () effectuer dans des conditions naturelles en comparant ce qui est plus rapide. Nous adaptons et prouvons le concept de notre exemple tiré d'ici. Considérez le code ci-dessous :

USE AdventureWorks
GO

SET STATISTICS TIME ON
SELECT CAST([NationalIDNumber] as int) FROM [HumanResources].[Employee]
SELECT CONVERT(int,[NationalIDNumber]) FROM [HumanResources].[Employee]
SELECT PARSE([NationalIDNumber] as int) FROM [HumanResources].[Employee]
SET STATISTICS TIME OFF
GO

Examinons maintenant le code qui utilise AdventureWorks base de données de Microsoft :

  • ACTIVER L'HEURE DES STATISTIQUES affichera le temps CPU et le temps écoulé dans chacun des SELECT déclarations
  • Ensuite, la colonne que nous choisissons de convertir à des fins de démonstration est [NationalIDNumber ], dont le type est nvarchar(15) .
  • En outre, la conversion se fait d'une chaîne en un entier :nvarchar(15) en entier .
  • Et enfin, nous restaurons le SET STATISTICS TIME à sa valeur précédente

Notez la sortie dans les Messages onglet du résultat de la requête :

Voici ce que nous avons trouvé en utilisant cet exemple :

  • Cela prouve que CAST () effectue le plus rapide (1 ms.) et PARSE () est la plus lente (318 ms).
  • Nous suivons cette priorité lors du choix de la fonction à utiliser pour convertir les données :(1 ) CAST () (2 ) CONVERTIR () (3 ) ANALYSE ().
  • Souvenez-vous quand chaque fonction est pertinente et tenez compte des limites lorsque vous décidez quelle fonction utiliser.

Comment fonctionne la conversion implicite

À ce stade, vous devriez pouvoir voir que je recommande l'utilisation de fonctions telles que CAST() pour convertir les données. Et dans cette section, vous verrez pourquoi.

Envisagez cette requête en utilisant les WideWorldImporters base de données de Microsoft. Avant de l'exécuter, veuillez activer l'option Inclure le plan d'exécution réel dans SQL Server Management Studio .

USE WideWorldImporters
GO
SELECT
[CustomerID]
,[OrderID]
,[OrderDate]
,[ExpectedDeliveryDate]
FROM [Sales].[Orders]
WHERE [CustomerID] like '487%'

Dans la requête ci-dessus, nous filtrons le résultat des commandes client avec [CustomerID ] comme "487 %". C'est juste pour montrer quel effet la conversion implicite d'un int le type de données a sur varchar .

Ensuite, nous examinons le plan d'exécution ci-dessous :

Comme vous pouvez le voir, il y a un avertissement dans le SELECT icône. Par conséquent, passez votre souris pour voir l'info-bulle. Ensuite, notez le message d'avertissement, à savoir le CONVERT_IMPLICIT .

Avant de continuer, ce CONVERT_IMPLICIT L'avertissement se produit lorsqu'il est nécessaire d'effectuer une conversion implicite pour SQL Server. Regardons de plus près le problème. Comme décrit ci-dessous, l'avertissement comporte 2 parties :

  • CONVERT_IMPLICIT peut affecter « CardinalalityEstimate » dans un choix de plan de requête.
  • CONVERT_IMPLICIT peut affecter "SeekPlan" dans un choix de plan de requête.

Les deux indiquent que votre requête s'exécutera plus lentement. Mais nous savons pourquoi, bien sûr. Nous forçons intentionnellement une conversion implicite en utilisant un LIKE opérateur pour une valeur entière.

Quel est l'intérêt de cela ?

  • La conversion implicite des données oblige SQL Server à utiliser CONVERT_IMPLICIT , ce qui ralentit l'exécution de votre requête.
  • Pour résoudre ce problème, éliminez l'utilisation de la conversion implicite. Dans notre cas, nous avons utilisé [CustomerID ] J'AIME '487 %', nous pouvons le réparer en changeant [CustomerID ] =487. La correction de la requête modifiera le plan d'exécution de la requête, supprimera l'avertissement plus tôt et changera l'opérateur d'analyse d'index en une recherche d'index. Au final, les performances s'améliorent.

Fin heureuse? Oui !

À emporter

Comme indiqué, nous ne pouvons pas simplement laisser SQL Server effectuer la conversion avec une conversion implicite. Je vous recommande de suivre la priorité lorsqu'il s'agit de décider quoi utiliser lors de la conversion des données.

  • Tout d'abord, si vous avez juste besoin de convertir tel quel, utilisez CAST (). Il s'agit d'une fonction plus standardisée lors du portage vers d'autres RDBM.
  • Deuxièmement, si vous avez besoin de données formatées, utilisez CONVERT ().
  • Troisièmement, si les deux CAST () et CONVERTIR () échouent à faire le travail, utilisez PARSE ().
  • Enfin, pour tester les erreurs lors de la conversion, utilisez TRY_CAST (), TRY_CONVERT (), ou TRY_PARSE ().

Bien, c'est tout pour le moment. J'espère que cela vous aidera dans vos prochaines aventures de codage. Casse-toi une jambe !

Pour en savoir plus sur le sujet de la conversion de données SQL de Microsoft :

  • CAST et CONVERT
  • ANALYSE
  • TRY_CAST, TRY_CONVERT et TRY_PARSE