PARSE() vs CAST() vs CONVERT() en SQL Server:¿Cuál es la diferencia?

Tal vez haya encontrado el T-SQL PARSE() , CAST() y CONVERT() funciona cuando se trabaja con SQL Server y se preguntó cuál es la diferencia. Las tres funciones parecen hacer lo mismo, pero hay diferencias sutiles entre ellas.

En este artículo pretendo esbozar las principales diferencias entre estas funciones.

Comparación

Aquí hay una tabla que describe las principales diferencias entre CONVERT() , CAST() y PARSE() funciones en SQL Server:

Algunos otros puntos además de la tabla anterior:

• La documentación de Microsoft señala que PARSE() no será remoto (ya que depende de la presencia del CLR). La transmisión remota de una función que requiere CLR provocaría un error en el servidor remoto.
• Hay algunos valores que PARSE() puede manejar pero CAST() y CONVERT() no puede (por ejemplo, cadenas que usan ciertos formatos de fecha).
• CAST() está incluido en el estándar ANSI SQL-92.
• Algunos argumentan que CAST() tiene un mejor rendimiento que los otros dos.
• Hay cierta sobrecarga de rendimiento cuando se analizan valores de cadena. Por lo tanto, PARSE() normalmente funcionará más lento que los otros dos.

A continuación se muestran ejemplos de situaciones en las que cada función sería la más adecuada.

Cuándo usar CAST()

Se podría hacer un buen argumento para usar CAST() para cualquier escenario que no esté en la lista a continuación. Como se mencionó, CAST() ha sido parte del estándar ANSI SQL desde SQL-92, por lo que debería ser más portátil entre diferentes DBMS (si ese es un requisito).

Además, algunos argumentan que CAST() tiene un mejor rendimiento que los otros dos (aquí hay un artículo interesante que compara el rendimiento entre las tres funciones).

Sin embargo, también hay razones válidas por las que podría preferir (o necesitar) usar CONVERT() sobre CAST() .

Cuándo usar CONVERTIR()

El CONVERT() La función puede ser útil cuando necesita usar el style argumento para especificar cómo debe formatearse la fecha al convertir entre una fecha y una cadena. Estos son algunos ejemplos:

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

Resultado:

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

Solo puedes hacer esto con CONVERT() porque:

• CAST() no admite el style argumento; y
• PARSE() no convierte de una fecha/hora a un valor de cadena (tampoco es compatible con el estilo style argumento)

Cuándo usar PARSE()

A pesar de las diversas desventajas de esta función (rendimiento, dependencia de .NET, conversiones de tipos de datos limitadas), también tiene algunas ventajas y hay algunos escenarios en los que podría ser su única opción. Por ejemplo, al proporcionar una fecha que incluye el nombre del día de la semana, como viernes, 20 de julio de 2018 .

Cuando los demás devuelven un error

Aquí hay ejemplos donde PARSE() es la única función de las tres que puede convertir con éxito el valor sin arrojar un error.

En estos ejemplos, intentamos convertir varios valores de cadena en una fecha tipo de datos. Sin embargo, los valores de cadena que proporcionamos incluyen el nombre del día de la semana. Esto causa problemas para CAST() y CONVERT() , pero PARSE() no tiene problema.

ANALIZAR()

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

Resultado:

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

Entonces PARSE() no tiene problema con el formato de la fecha que le proporcionamos.

CONVERTIR()

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

Resultado:

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

Entonces CONVERT() no puede convertir la cadena cuando está en ese formato.

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

Resultado:

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

Y CAST() devuelve el mismo error.

Entonces, si encuentra errores con las otras dos funciones, intente PARSE() en su lugar.

Especificar la Cultura

Otro escenario en el que podría preferir usar el PARSE() La función es cuando se especifica la cultura/idioma en el que se proporciona la cadena. PARSE() tiene un argumento opcional que le permite especificar qué cultura usar. Si se omite, se utiliza el idioma de la sesión actual.

Ejemplo de inclusión de la culture argumento:

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

Resultado:

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

Una alternativa cultural

A pesar del beneficio de poder especificar la cultura con PARSE() , tiene la capacidad de cambiar la configuración de idioma, lo que significa que podría lograr el mismo efecto al usar CAST() o CONVERT() .

Por ejemplo, usando SET LANGUAGE us_english antes de la consulta cambiará la configuración de idioma actual a us_english . Si bien esto no le permite especificar diferentes culturas dentro de la consulta (como en el ejemplo anterior), sí afecta a toda la consulta (y cualquier consulta posterior).

También puede cambiar la configuración del formato de fecha de la misma manera. Por ejemplo, SET DATEFORMAT mdy .

Aquí hay un ejemplo de cómo cambiar la configuración de idioma antes de ejecutar una consulta con CAST() y CONVERT() :

Alemán:

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

Resultado:

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

Resultado:

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

Recuerde, cuando hace esto, está cambiando el entorno de idioma/formato de fecha para la sesión. ¡No olvides volver a cambiarlo!