Tal vez se haya encontrado con las funciones T-SQL PARSE(), CAST() y CONVERT() al trabajar con SQL Server y se haya preguntado cuál es la diferencia. Las tres funciones parecen hacer lo mismo, pero hay sutiles diferencias entre ellas.
En este artículo pretendo exponer las principales diferencias entre estas funciones.
Comparación
Aquí hay una tabla que resume las principales diferencias entre las funciones CONVERT(), CAST() y PARSE() de SQL Server:
| CONVERTIR() | CAST() | PARSE() | |
|---|---|---|---|
| Definición oficial | Convierte una expresión de un tipo de datos a otro. | Convierte una expresión de un tipo de datos a otro. | Devuelve el resultado de una expresión, traducido al tipo de datos solicitado en SQL Server. |
| Valor Aceptado | Cualquier expresión válida. | Cualquier expresión válida. | Cadena. |
| Valor de retorno | Segundo argumento, traducido al tipo de datos solicitado según lo proporcionado por el primer argumento. | 1er argumento, traducido al tipo de datos solicitado según lo proporcionado por el 2º argumento. | 1er argumento, traducido al tipo de datos solicitado según lo proporcionado por el 2º argumento. |
| Conversiones admitidas | Entre dos tipos de datos cualesquiera. | Entre dos tipos de datos cualesquiera. | De cadena a fecha/hora y tipos numéricos solamente. |
| ¿Acepta el argumento de estilo? | Sí. | No. | No. |
| ¿Acepta el argumento cultura? | No. | No. | Sí. |
| ¿Requiere .NET Framework? | No. | No. | Sí. |
Algunos otros puntos además de la tabla anterior:
- La documentación de Microsoft señala que
PARSE()no se remotará (ya que depende de la presencia del CLR). Remotar una función que requiere el CLR causaría un error en el servidor remoto. - Hay algunos valores con los que
PARSE()puede tratar peroCAST()yCONVERT()no (por ejemplo, cadenas que utilizan ciertos formatos de fecha). -
CAST()está incluido en el estándar ANSI SQL-92. - Algunos argumentan que
CAST()tiene mejor rendimiento que los otros dos. - Hay una cierta sobrecarga de rendimiento cuando se analizan valores de cadena. Por lo tanto,
PARSE()se ejecutará típicamente más lento que los otros dos.
A continuación se presentan ejemplos de situaciones en las que cada función sería la más adecuada.
Cuándo utilizar CAST()
Un buen argumento podría ser hecho para el uso de CAST() para cualquier escenario que no está en la lista de abajo. Como se ha mencionado, CAST() ha sido parte del estándar ANSI SQL desde SQL-92, por lo que debería ser más portable entre diferentes DBMSs (si es un requisito).
Además, algunos argumentan que CAST() tiene mejor rendimiento que las otras dos (aquí hay un interesante artículo que compara el rendimiento entre las tres funciones).
Sin embargo, también hay razones válidas por las que podría preferir (o necesitar) utilizar CONVERT() en lugar de CAST().
Cuándo utilizar CONVERT()
La función CONVERT() puede ser útil cuando se necesita utilizar el argumento style para especificar cómo debe formatearse la fecha al convertir entre una fecha y una cadena. Aquí hay 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 |+---------------------+------------+------------+------------+
Sólo puede hacer esto con CONVERT() porque:
-
CAST()no admite el argumentostyle; y -
PARSE()no convierte de un valor de fecha/hora a un valor de cadena (tampoco admite el argumentostyle)
Cuándo utilizar PARSE()
A pesar de las diversas desventajas de esta función (rendimiento, dependencia de .NET, conversiones limitadas de tipos de datos), también tiene algunas ventajas, y hay algunos escenarios en los que podría ser su única opción. Por ejemplo, cuando se proporciona una fecha que incluye el nombre del día de la semana, como el viernes 20 de julio de 2018.
Cuando los demás devuelven un error
Aquí hay ejemplos en los que PARSE() es la única función de las tres que puede convertir con éxito el valor sin lanzar un error.
En estos ejemplos, intentamos convertir varios valores de cadena a un tipo de datos de fecha. 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 ningún problema.
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';
Resultado:
+------------+------------+------------+| Result 1 | Result 2 | Result 3 ||------------+------------+------------|| 2018-07-20 | 2018-07-20 | 2018-07-20 |+------------+------------+------------+
Así que PARSE() no tiene ningún problema con el formato de la fecha que proporcionamos.
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';
Resultado:
Conversion failed when converting date and/or time from character string.
Así que 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.
Así que si te encuentras con errores con las otras dos funciones, prueba con PARSE() en su lugar.
Especificación de la cultura
Otro escenario en el que puede preferir utilizar la función PARSE() es cuando se especifica la cultura/idioma en la que se proporciona la cadena. PARSE() tiene un argumento opcional que le permite especificar qué cultura utilizar. Si se omite, se utiliza el idioma de la sesión actual.
Ejemplo de incluir el argumento 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';
Resultado:
+------------+------------+| Result 1 | Result 2 ||------------+------------|| 2018-07-01 | 2018-01-07 |+------------+------------+
Una alternativa de cultura
A pesar de la ventaja de poder especificar la cultura con PARSE(), tiene la posibilidad de cambiar la configuración del idioma, lo que significa que podría lograr el mismo efecto al utilizar CAST() o CONVERT().
Por ejemplo, el uso de SET LANGUAGE us_english antes de la consulta cambiará la configuración del idioma actual a us_english. Aunque esto no le permite especificar diferentes culturas dentro de la consulta (como en el ejemplo anterior), sí afecta a toda la consulta (y a cualquier consulta posterior).
También puede cambiar la configuración del formato de la fecha de la misma manera. Por ejemplo, SET DATEFORMAT mdy.
Aquí hay un ejemplo de cambio de la configuración del 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 |+------------+
Recuerda que cuando haces esto, estás cambiando el entorno de idioma/formato de fecha para la sesión. No se olvide de volver a cambiarlo!