Database
 sql >> Datenbank >  >> RDS >> Database

4 sofort einsatzbereite SQL-Datenkonvertierungsmethoden und Anwendungsfälle

Erstens geht es nicht ohne sie, oder?

SQL-Datenkonvertierungen oder genauer gesagt Datentypkonvertierungen sind ein wesentlicher Bestandteil der regelmäßigen Programmierarbeit eines Datenbankentwicklers oder DBAs.

Was wäre nun, wenn Ihr Chef einen Vertrag mit einem anderen Unternehmen abschließen würde, um ihm eine Datei im Textformat aus Ihrer SQL Server-Datenbank zur Verfügung zu stellen?

Das klingt nach einer spannenden Herausforderung!

Aber Sie haben herausgefunden, dass Sie sich mit einem Datum in eine Zeichenfolge, einer Zahl in eine Zeichenfolge und einer Reihe anderer SQL-Datenkonvertierungen befassen müssen. Bist du immer noch bereit für die Herausforderung?

Nicht ohne Ihr Arsenal an Datenkonvertierungstricks!

Was ist sofort einsatzbereit?

Als ich mit der T-SQL-Programmierung anfing, war das erste, was ich sah, das zum Zweck der Konvertierung passte, CONVERT () Funktion.

Außerdem ist das Wort „konvertieren“ da, richtig?

Obwohl dies wahr sein mag, ist es nur eine der 4 Möglichkeiten, diesen Job auszuführen. Und ich habe es für fast ALLE meine SQL-Datenkonvertierung verwendet. Ich bin froh, dass ich darüber hinweg bin. Weil ich gelernt habe, dass die 4 Methoden ihren eigenen Platz in Ihrem Code haben.

Bevor wir zum Thema des Beitrags kommen, lassen Sie mich die 4 sofort einsatzbereiten Methoden zur Durchführung der SQL-Datenkonvertierung vorstellen:

  • CAST ()
  • KONVERTIEREN ()
  • PARSE ()
  • TRY_CAST (), TRY_CONVERT (), TRY_PARSE ()

Jeder der folgenden Abschnitte wird:

  • Erklären Sie, was es ist
  • Ihnen sagen, wann Sie es verwenden sollen (Anwendungsfälle)
  • Präsentieren Sie seine Einschränkungen
  • Geben Sie Beispiele und erklären Sie es

Alles, was in diesem Artikel dargestellt wird, ist so weit wie möglich in einfachem, einfachem Englisch. Wenn Sie den gesamten Beitrag gelesen haben, wissen Sie, welche Methode für eine bestimmte Situation geeignet ist.

Lassen Sie uns also ohne weiteres eintauchen.

1. SQL-Datenkonvertierung mit CAST()

Während alle Methoden, die Sie sehen werden, Datentypen konvertieren können, sollte Ihre erste Wahl beim Konvertieren definitiv CAST sein ().

Hier sind die Gründe dafür:

  • Es ist die am schnellsten laufende Konvertierungsfunktion von allen. Wir werden versuchen, dies später in diesem Beitrag zu beweisen.
  • Es ist in den SQL-92-Sprachspezifikationsstandards enthalten. Wenn Sie also Ihren Code auf andere SQL-Produkte wie MySQL portieren müssen, steht die Funktion ebenfalls zur Verfügung.

Hier ist eine sehr einfache Syntax für CAST ():

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

Lassen Sie uns zunächst die Syntax untersuchen:

  • <Ausdruck> ist ein beliebiger gültiger Ausdruck, der zu einem Wert führt, der in den Zieldatentyp konvertiert werden kann.
  • <Datentyp> ist der Zieldatentyp.
  • Länge ist optional und hängt von der Größe der Daten ab.

Wann man es verwendet

Wenn Sie nur einen Wert in einen anderen Datentyp konvertieren müssen, dann CAST () ist genau das, was Sie brauchen.

Einschränkung

Auf der negativen Seite, CAST () kann Ihnen keine sofort einsatzbereite formatierte Ausgabe wie einen formatierten Datums- und Zeitwert geben.

Beispiele

A. Konvertieren Sie eine Zeichenfolge in ein Datum: 

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

Und die Ausführung der obigen Anweisung führt zu:

B. Wandeln Sie eine Zahl in einen String um: 

SELECT CAST(10.003458802 as varchar(max))

Und das Ergebnis der obigen Konvertierung ist:

Wenn Sie jetzt etwas anderes benötigen, wie z. B. das Formatieren der konvertierten Daten, kann Ihnen die nächste Methode helfen.

2. SQL-Datenkonvertierung mit CONVERT()

Die nächste Option der Datenkonvertierung ist die Verwendung von CONVERT (). Wie ich bereits sagte, ist dies diejenige, die ich früher am häufigsten verwendet habe.

Hier ist die Syntax:

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

Beachten Sie bei der obigen Syntax, dass der <style> Parameter ist optional. Und wenn Sie es nicht angeben, ähnelt die Funktion CAST ().

Hier begann meine Verwirrung, als ich neu bei SQL war.

Wann man es verwendet

Wenn Sie die Daten mit einem Instant-Format konvertieren, dann CONVERT () ist dein Freund. Das heißt, Sie behandeln den <Stil> richtig parametrieren.

Einschränkungen

  • CAST () ist schneller als CONVERT (), wenn Sie also nur die Daten konvertieren müssen, verwenden Sie CAST (). Wenn die Ausgabe formatiert werden soll, verwenden Sie CONVERT ().
  • KONVERTIEREN () ist kein SQL-92-Standard, wenn Sie es also auf andere RDBMS portieren müssen, verwenden Sie es nicht.

Beispiele

A. Konvertieren Sie ein Datum in ein Zeichenfolgenformat jjjjmmtt

Im folgenden Beispiel verwende ich die Beispieldatenbank AdventureWorks und transformieren Sie das [StartDate ]-Spalte zu jjjjmmtt :

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

Beachten Sie, dass Stil 112 zum Formatieren von Datumsangaben in jjjjmmtt verwendet wird .

B. Konvertieren Sie eine Zahl in eine Zeichenfolge mit Kommas an allen 3 Stellen links vom Dezimalkomma.

In ähnlicher Weise veranschaulicht das folgende Beispiel AdventureWorks Beispieldatenbank, und wir formatieren die Zahl mit Kommas und mit 2 Dezimalstellen.

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

Beachten Sie, dass Format 1 für [ActualCost verwendet wird ]. Und dank CONVERT (), können wir diese Spalten sofort formatieren.

Was aber, wenn Sie einen längeren Datumsausdruck konvertieren müssen? Wird KONVERTIEREN () Arbeit in diesem Fall? Lesen Sie weiter, um mehr über die nächste Methode zu erfahren.

3. SQL-Datenkonvertierung mit PARSE()

Die nächste Methode, die wir betrachten werden, ist PARSE ().

Sehen Sie sich die Syntax an:

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

Wann man es verwendet

  • Zum Konvertieren von Zeichenfolgen in Datumsangaben oder Zahlen unter Verwendung einer bestimmten Kultur.
  • Wenn die Zeichenfolge mit CAST nicht in ein Datum oder eine Zahl umgewandelt werden kann () oder KONVERTIEREN (). Weitere Informationen finden Sie in den Beispielen.

Einschränkungen

  • Konvertierung ist nur für Strings in Datumsangaben und Strings in Zahlen möglich
  • Hängt vom Vorhandensein von .Net Framework Common Language Runtime (CLR) auf dem Server ab.
  • Ist nicht in den SQL-92-Standardspezifikationen enthalten, daher ist die Portierung auf andere RDBMS ein Problem.
  • Hat Leistungseinbußen beim Analysieren der Zeichenfolge.

Beispiele

A. Konvertieren einer langen Datumszeichenfolge 

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

Das obige Beispiel ist eine lange Datumszeichenfolge, die in ein datetime konvertiert werden soll Wert unter Verwendung der US-englischen Kultur. Und hier PARSE () wird sein Bestes geben.

Das liegt daran, dass der obige Code fehlschlägt, wenn Sie CAST verwenden () oder KONVERTIEREN ().

B. Einen Geldwert mit einem Währungssymbol umrechnen 

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

Versuchen Sie nun, die Konvertierung mit CAST durchzuführen () und KONVERTIEREN ()

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

Die Anweisung löst keine Fehler aus, sehen Sie sich dennoch dieses unerwartete Ergebnis an:

Daher wurde der Wert in 102401,00 statt 1024,01 umgewandelt.

Bisher haben wir festgestellt, dass die ersten 3 Methoden fehleranfällig sind, wenn Sie sie nicht überprüfen. Trotzdem kann die 4. Methode Ihre Lösung für das fehlerhafte Ergebnis sein.

4. SQL-Datenkonvertierung mit TRY_CAST(), TRY_CONVERT() oder TRY_PARSE()

Schließlich verwendet die letzte Methode für die SQL-Datenkonvertierung eine Variante der ersten 3, jedoch mit dem Präfix TRY_.

Aber trotzdem, was ist der Unterschied?

Sie haben die gleichen Parameter wie die vorherigen 3 ohne das Präfix TRY_. Aber der Unterschied ist, dass sie NULL zurückgeben wenn der Wert nicht konvertiert werden kann. Wenn der Wert jetzt nicht explizit von einem der 3 konvertiert werden kann, tritt ein Fehler auf. Sehen Sie sich die Beispiele unten zum besseren Verständnis an.

Wann man es verwendet

Sie können jede der 3 mit bedingten Anweisungen wie CASE verwenden WANN oder IIF um auf Fehler zu testen.

Einschränkungen

Die 3 von ihnen haben die gleichen Einschränkungen wie die ohne das Präfix TRY_, mit Ausnahme von Werten, die nicht konvertiert werden können.

Beispiele

A. Verwenden Sie TRY_CAST(), um zu testen, ob die Konvertierung mit IIF erfolgreich sein wird: 

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

Der obige Code gibt „Cast Failed“ zurück, da „111b“ nicht in echt konvertiert werden kann . Nehmen Sie das „b“ aus dem Wert weg und es wird „Übertragung erfolgreich“ zurückgegeben.

B. Verwenden von TRY_CONVERT() für Daten mit einem bestimmten Format 

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

Dies gibt NULL zurück weil das Format dmy verwendet oder Tag-Monat-Jahr. Und der Eingabeausdruck für TRY_CONVERT () hat das Format mdy oder Monat-Tag-Jahr. Der Fehler wurde ausgelöst, weil der Monatswert 31 ist.

C. Verwenden von TRY_PARSE(), das einen Laufzeitfehler generiert 

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

Dieser Code generiert einen Laufzeitfehler wie unten gezeigt:

Das war es für die 4 sofort einsatzbereiten Methoden in der SQL-Datenkonvertierung. Aber es kommt noch mehr.

Wie wäre es mit einer SQL-Datenkonvertierung mit impliziter Konvertierung?


Betrachten wir nun die implizite Konvertierung. Dies ist eine stille Methode.

Warum schweigen?

Weil du es vielleicht schon tust, aber dir dessen nicht bewusst bist. Oder zumindest weißt du, dass es passiert, aber du ignorierst es.

Mit anderen Worten, dies ist die Art der Konvertierung, die SQL automatisch ohne Funktionen durchführt.

Lassen Sie mich Ihnen ein Beispiel geben:

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]

Der obige Code wird erfolgreich ausgeführt. Probieren Sie es selbst aus und Sie werden ein ähnliches Ergebnis wie das folgende haben:

Versuchen wir es mit Datumsangaben:

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]

Wie erwartet führt dies zu einem erfolgreichen Ergebnis:

Versuchen wir es diesmal mit Zahlen:

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]

Immer noch ein Erfolg, oder?

Bisher haben wir einfache Werte verwendet, die für einen ziemlich ähnlichen Datentyp geeignet sind. Kommen wir zum nächsten Level:Zahlen zu Strings.

DECLARE @number int
DECLARE @string varchar(5)

SET @number = 1701
SET @string = @number

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

Dies wird erfolgreich konvertiert, wie Sie dem Ergebnis unten entnehmen können:

Es gibt viele weitere Fälle, in denen SQL Server versucht, zu „raten“, wie Daten konvertiert werden. Wie Sie dieser Referenz entnehmen können, gibt es viele Fälle im Vergleich zu denen, die eine explizite Konvertierung erfordern.

Da SQL Server dies zulässt, bedeutet dies, dass Sie dies in Ihrem gesamten Code frei zulassen können?

Vorbehalte bei der impliziten Konvertierung

Zum einen mag es bequem sein. Aber sobald die Grenzen jedes Datentyps erreicht sind, werden Sie feststellen, dass die implizite Konvertierung etwas gefährlich ist, wenn sie nicht aktiviert wird.

Betrachten Sie ein Beispiel unten:

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]

Hast du den Emoji-Wert gesehen? Das zählt als Unicode-Wert.

Während alle obigen Anweisungen erfolgreich ausgeführt werden, sind die Variablen mit Nicht-Unicode-Typen wie varchar und char wird unerwartete Ergebnisse haben. Sehen Sie sich das Ergebnis unten an:

Allerdings ist das nicht das einzige Problem. Fehler werden angezeigt, wenn der Wert außerhalb des zulässigen Bereichs liegt. Betrachten Sie ein Beispiel mit Datumsangaben:

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]

Die Zuweisung der datetime Wert auf smalldatetime Variable wird den Fehler auslösen, wie Sie unten sehen können:

Aber es gibt noch einen weiteren Vorbehalt, den Sie beim Umgang mit impliziter Konvertierung beachten sollten:den Leistungsaufwand. Da dies ein heißes Thema ist, verdient es einen eigenen Abschnitt.

Auswirkungen verschiedener SQL-Datenkonvertierungsmethoden auf die Leistung

Ob Sie es glauben oder nicht, verschiedene SQL-Datenkonvertierungsmethoden haben in tatsächlichen Situationen eine unterschiedliche Leistung. Und Sie sollten sich dessen zumindest bewusst sein, damit Sie Leistungsfallen vermeiden können.

Wie CAST(), CONVERT() und PARSE() funktionieren

Lassen Sie uns zunächst untersuchen, wie CAST (), KONVERTIEREN () und PARSE () unter natürlichen Bedingungen durchführen, indem verglichen wird, was schneller ist. Wir adaptieren und beweisen das Konzept unseres hier entnommenen Beispiels. Betrachten Sie den folgenden Code:

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

Sehen wir uns nun den Code an, der AdventureWorks verwendet Datenbank von Microsoft:

  • STATISTIKZEIT EINSTELLEN gibt die CPU-Zeit und die verstrichene Zeit in jedem der SELECT aus Aussagen
  • Dann ist die Spalte, die wir zu Demonstrationszwecken konvertieren, [NationalIDNumber ], die einen Typ von nvarchar(15) hat .
  • Außerdem erfolgt die Umwandlung von einem String in eine ganze Zahl:nvarchar(15) zu int .
  • Und zuletzt stellen wir die STATISTIKZEIT EINSTELLEN wieder her auf den vorherigen Wert

Beachten Sie die Ausgabe in den Nachrichten Registerkarte des Abfrageergebnisses:

Folgendes haben wir anhand dieses Beispiels herausgefunden:

  • Das beweist, dass CAST () ist am schnellsten (1 ms) und PARSE () ist am langsamsten (318 ms).
  • Wir folgen dieser Priorität bei der Entscheidung, welche Funktion zum Konvertieren von Daten verwendet werden soll:(1 ) CAST () (2 ) KONVERTIEREN () (3 ) PARSE ().
  • Denken Sie daran, wann welche Funktion relevant ist, und berücksichtigen Sie die Einschränkungen, wenn Sie entscheiden, welche Funktion verwendet werden soll.

Leistung der impliziten Konvertierung

An dieser Stelle sollten Sie erkennen können, dass ich die Verwendung von Funktionen wie CAST() zum Konvertieren von Daten empfehle. Und in diesem Abschnitt erfahren Sie warum.

Betrachten Sie diese Abfrage mit WideWorldImporters Datenbank von Microsoft. Aktivieren Sie vor der Ausführung bitte die Option Aktuellen Ausführungsplan einschließen in SQL Server Management Studio .

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

In der obigen Abfrage filtern wir das Ergebnis von Verkaufsaufträgen mit [CustomerID ] wie „487 %“. Dies soll nur demonstrieren, was die implizite Konvertierung eines int bewirkt Datentyp hat auf varchar .

Als Nächstes untersuchen wir den folgenden Ausführungsplan:

Wie Sie sehen können, gibt es eine Warnung im SELECT Symbol. Bewegen Sie daher die Maus, um den Tooltip anzuzeigen. Beachten Sie als Nächstes die Warnmeldung, nämlich CONVERT_IMPLICIT .

Bevor wir fortfahren, dieses CONVERT_IMPLICIT Warnung tritt auf, wenn es notwendig ist, eine implizite Konvertierung für SQL Server durchzuführen. Schauen wir uns das Problem genauer an. Wie unten beschrieben, besteht die Warnung aus zwei Teilen:

  • CONVERT_IMPLICIT kann „CardinalityEstimate“ bei der Auswahl eines Abfrageplans beeinflussen.
  • CONVERT_IMPLICIT kann „SeekPlan“ bei der Auswahl eines Abfrageplans beeinflussen.

Beide zeigen an, dass Ihre Abfrage langsamer ausgeführt wird. Aber wir wissen natürlich warum. Wir erzwingen absichtlich eine implizite Konvertierung, indem wir ein LIKE verwenden Operator für einen ganzzahligen Wert.

Was soll das?

  • Die implizite Konvertierung von Daten führt dazu, dass SQL Server CONVERT_IMPLICIT verwendet , wodurch die Abfrageausführung verlangsamt wird.
  • Um dieses Problem zu beheben, eliminieren Sie die Verwendung der impliziten Konvertierung. In unserem Fall haben wir [Kunden-ID verwendet ] WIE „487 %“, wir können es beheben, indem wir die [Kunden-ID ändern ] =487. Durch das Korrigieren der Abfrage wird der Abfrageausführungsplan geändert, die Warnung früher entfernt und der Index-Scan-Operator in eine Indexsuche geändert. Am Ende verbessert sich die Leistung.

Happy End? Ja!

Imbiss

Wie gezeigt, können wir nicht einfach SQL Server die Konvertierung mit einer impliziten Konvertierung überlassen. Ich empfehle Ihnen, bei der Entscheidung, was beim Konvertieren von Daten verwendet werden soll, den Vorrang einzuhalten.

  • Wenn Sie zunächst nur so konvertieren müssen, wie es ist, verwenden Sie CAST (). Es ist eine eher standardisierte Funktion, wenn es um die Portierung auf andere RDBMs geht.
  • Zweitens, wenn Sie formatierte Daten benötigen, verwenden Sie CONVERT ().
  • Drittens, wenn beide CAST () und KONVERTIEREN () die Aufgabe nicht erfüllen, verwenden Sie PARSE ().
  • Zu guter Letzt, um beim Konvertieren auf Fehler zu testen, verwenden Sie TRY_CAST (), TRY_CONVERT () oder TRY_PARSE ().

Also ..., das wäre es erst einmal. Ich hoffe, dies hilft Ihnen bei Ihren nächsten Programmierabenteuern. Bein brechen!

Um mehr zum Thema SQL-Datenkonvertierung von Microsoft zu erfahren:

  • CAST und CONVERT
  • PARSE
  • TRY_CAST, TRY_CONVERT und TRY_PARSE