T-SQL Cast versus Convert

325

¿Cuál es la guía general sobre cuándo debe usar CASTversus CONVERT? ¿Hay algún problema de rendimiento relacionado con elegir uno versus el otro? ¿Está uno más cerca de ANSI-SQL?

— BuddyJoe
fuente

339

CONVERTes específico de SQL Server, CASTes ANSI.

CONVERTes más flexible ya que puedes formatear fechas, etc. Aparte de eso, son más o menos lo mismo. Si no te interesan las funciones ampliadas, úsalas CAST.

EDITAR:

Como lo señalan @beruic y @CF en los comentarios a continuación, existe una posible pérdida de precisión cuando se usa una conversión implícita (es decir, donde no se usa CAST ni CONVERT). Para obtener más información, vea CAST y CONVERT y, en particular, este gráfico: Tabla de conversión de tipos de datos de SQL Server . Con esta información adicional, el consejo original sigue siendo el mismo. Use CAST donde sea posible.

— Matthew Farwell
fuente

55

Además, creo que hay algunas conversiones numéricas donde CAST debería usarse para preservar la precisión, pero tengo problemas para encontrar una fuente confiable para esta información.

— beruic

2

@beruic Tienes razón, hay información en MSDN: msdn.microsoft.com/en-us/library/ms187928.aspx CAST es necesario para preservar la precisión al convertir entre los tipos DECIMAL y NUMERIC.

— CF

@CF ¿Dónde ve esta información? He seguido el enlace, que abre la página general sobre CAST y CONVERT, y la única información sobre precisión que puedo encontrar es sobre la conversión de valores flotantes que usan notación científica. ¿Puedo estar equivocado en mi comentario inicial?

— beruic

66

@beruic Se trata de esta imagen en la parte inferior del artículo i.msdn.microsoft.com/dynimg/IC170617.gif Ahora creo que tal vez la pérdida de precisión puede ocurrir en la conversión implícita y no ocurre cuando se usa CAST o CONVERT . No está del todo claro ...

— CF

2

@CF Estoy de acuerdo en que no está muy claro, y definitivamente debería haber documentación más específica al respecto, así que esperemos que Microsoft haga esto. Pero bien visto allí :)

— beruic

29

Convertir tiene un parámetro de estilo para las conversiones de fecha a cadena.

http://msdn.microsoft.com/en-us/library/ms187928.aspx

— jason saldo
fuente

12

CAST es SQL estándar, pero CONVERT es solo para el dialecto T-SQL. Tenemos una pequeña ventaja para convertir en el caso de datetime.

Con CAST, indica la expresión y el tipo de destino; Con CONVERT, hay un tercer argumento que representa el estilo para la conversión, que es compatible con algunas conversiones, como entre cadenas de caracteres y valores de fecha y hora. Por ejemplo, CONVERTIR (FECHA, '1/2/2012', 101) convierte la cadena de caracteres literales a FECHA utilizando el estilo 101 que representa el estándar de los Estados Unidos.

— Abdeloihab Bourassi
fuente

8

Para ampliar la respuesta anterior _{copiada por Shakti} , he podido medir una diferencia de rendimiento entre las dos funciones.

Estaba probando el rendimiento de las variaciones de la solución a esta pregunta y descubrí que la desviación estándar y los tiempos de ejecución máximos eran mayores cuando se usaba CAST.

_{* Tiempos en milisegundos, redondeados a la 1/300 de segundo más cercana según la precisión del DateTimetipo}

— Elaskanator
fuente

6

Algo que nadie parece haber notado todavía es la legibilidad. Teniendo…

CONVERT(SomeType,
    SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    )

... puede ser más fácil de entender que ...

CAST(SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    AS SomeType
    )

— Atario
fuente

2

Pero, creo que el CAST suele ser más legible. CAST(Column1 AS int)es más lógico leer que CONVERT(int, Column1)incluso para expresiones largas

— S.Serpooshan

4

CAST utiliza el estándar ANSI. En caso de portabilidad, esto funcionará en otras plataformas. CONVERT es específico para el servidor sql. Pero es una función muy fuerte. Puede especificar diferentes estilos para fechas

— RakeshP
fuente