Conversão T-SQL versus conversão

325

Qual é a orientação geral sobre quando você deve usar CASTversus CONVERT? Existe algum problema de desempenho relacionado à escolha de um versus o outro? Há alguém mais próximo do ANSI-SQL?

— BuddyJoe
fonte

339

CONVERTé específico do SQL Server, CASTé ANSI.

CONVERTé mais flexível, pois você pode formatar datas etc. Além disso, elas são praticamente iguais. Se você não se importa com os recursos estendidos, use CAST.

EDITAR:

Conforme observado por @beruic e @CF nos comentários abaixo, há uma possível perda de precisão quando uma conversão implícita é usada (que é onde você não usa nem CAST nem CONVERT). Para obter mais informações, consulte CAST e CONVERT e, em particular, este gráfico: Gráfico de conversão de tipos de dados do SQL Server . Com essas informações extras, o conselho original permanece o mesmo. Use CAST sempre que possível.

— Matthew Farwell
fonte

5

Além disso, acredito que há algumas conversões numéricas em que o CAST deve ser usado para preservar a precisão, mas estou tendo problemas para encontrar uma fonte confiável para essas informações.

— Beruic

2

@beruic Você está certo, há informações no MSDN: msdn.microsoft.com/en-us/library/ms187928.aspx O CAST é necessário para preservar a precisão ao converter entre os tipos DECIMAL e NUMÉRICO.

— CF

@ CF Onde você vê essas informações? Eu segui o link, que abre a página geral em CAST e CONVERT, e as únicas informações sobre precisão que posso encontrar são sobre a conversão de valores flutuantes que usam notação científica. Posso estar errado no meu comentário inicial?

— 22714 beruic

6

@beruic É sobre esta imagem na parte inferior do artigo: i.msdn.microsoft.com/dynimg/IC170617.gif Agora acho que talvez a perda de precisão possa ocorrer na conversão implícita e não ocorra quando CAST ou CONVERT for usado . Não está muito claro ... #

— 2020 CF

2

@ CF Concordo que não é muito claro, e definitivamente deveria haver documentação mais específica sobre o assunto, então esperamos que a Microsoft faça isso. Mas bem visto lá :)

— beruic

29

O Convert tem um parâmetro de estilo para a conversão de data em string.

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

— jason saldo
fonte

12

CAST é SQL padrão, mas CONVERT é apenas para o dialeto T-SQL. Temos uma pequena vantagem para converter no caso de data e hora.

Com CAST, você indica a expressão e o tipo de destino; com CONVERT, existe um terceiro argumento que representa o estilo da conversão, suportado por algumas conversões, como entre cadeias de caracteres e valores de data e hora. Por exemplo, CONVERT (DATE, '1/2/2012', 101) converte a cadeia de caracteres literal em DATE usando o estilo 101 que representa o padrão dos Estados Unidos.

— Abdeloihab Bourassi
fonte

8

Para expandir a resposta acima _{copiada por Shakti} , consegui medir uma diferença de desempenho entre as duas funções.

Eu estava testando o desempenho das variações da solução para essa pergunta e descobri que o desvio padrão e os tempos de execução máximos eram maiores ao usar CAST.

_{* Vezes em milissegundos, arredondados para o 1/300 de segundo mais próximo, conforme a precisão do DateTimetipo}

— Elaskanator
fonte

6

Algo que ninguém parece ter notado ainda é legibilidade. Tendo…

CONVERT(SomeType,
    SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    )

... pode ser mais fácil de entender do que ...

CAST(SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    AS SomeType
    )

— Atario
fonte

2

Mas acho que o CAST geralmente é mais legível. CAST(Column1 AS int)é mais lógico para ler do que CONVERT(int, Column1)mesmo para expressões longas

— S.Serpooshan

4

O CAST usa o padrão ANSI. Em caso de portabilidade, isso funcionará em outras plataformas. CONVERT é específico para o servidor sql. Mas é uma função muito forte. Você pode especificar estilos diferentes para datas

— RakeshP
fonte