PARSE() vs CAST() vs CONVERT() no SQL Server:Qual é a diferença?

Talvez você tenha encontrado o T-SQL PARSE() , CAST() e CONVERT() funções ao trabalhar com SQL Server e se perguntou qual é a diferença. Todas as três funções parecem fazer a mesma coisa, mas há diferenças sutis entre elas.

Neste artigo pretendo delinear as principais diferenças entre essas funções.

Comparação

Aqui está uma tabela que descreve as principais diferenças entre o CONVERT() , CAST() e PARSE() funções no SQL Server:

	CONVERTER()	CAST()	PARSE()
Definição oficial	Converte uma expressão de um tipo de dados em outro.	Converte uma expressão de um tipo de dados em outro.	Retorna o resultado de uma expressão, traduzida para o tipo de dados solicitado no SQL Server.
Valor aceito	Qualquer expressão válida.	Qualquer expressão válida.	Sequência.
Valor de retorno	2º argumento, traduzido para o tipo de dados solicitado conforme fornecido pelo 1º argumento.	1º argumento, traduzido para o tipo de dados solicitado conforme fornecido pelo segundo argumento.	1º argumento, traduzido para o tipo de dados solicitado conforme fornecido pelo segundo argumento.
Conversões compatíveis	Entre dois tipos de dados.	Entre dois tipos de dados.	Somente tipos de string para data/hora e número.
Aceita o estilo Argumento?	Sim.	Não.	Não.
Aceita a cultura Argumento?	Não.	Não.	Sim.
Requer o .NET Framework?	Não.	Não.	Sim.

Alguns outros pontos além da tabela acima:

A documentação da Microsoft indica que PARSE() não será remoto (pois depende da presença do CLR). A remoção remota de uma função que requer o CLR causaria um erro no servidor remoto.
Existem alguns valores que PARSE() pode lidar, mas CAST() e CONVERT() não pode (por exemplo, strings usando determinados formatos de data).
CAST() está incluído no padrão ANSI SQL-92.
Alguns argumentam que CAST() tem melhor desempenho do que os outros dois.
Há uma certa sobrecarga de desempenho ao analisar valores de string. Portanto, PARSE() normalmente será mais lento que os outros dois.

Abaixo estão exemplos de situações em que cada função seria a mais adequada.

Quando usar CAST()

Um bom argumento pode ser feito para usar CAST() para qualquer cenário que não esteja listado abaixo. Como mencionado, CAST() faz parte do padrão ANSI SQL desde o SQL-92, portanto, deve ser mais portátil entre diferentes DBMSs (se isso for um requisito).

Além disso, alguns argumentam que CAST() tem melhor desempenho que os outros dois (aqui está um artigo interessante que compara o desempenho entre as três funções).

No entanto, também há motivos válidos para você preferir (ou precisar) usar CONVERT() sobre CAST() .

Quando usar CONVERT()

O CONVERT() pode ser útil quando você precisa usar o style argumento para especificar como a data deve ser formatada ao converter entre uma data e uma string. aqui estão alguns exemplos:

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

Você só pode fazer isso com CONVERT() Porque:

CAST() não suporta o style argumento; e
PARSE() não converte de uma data/hora para um valor de string (também não suporta o style argumento)

Quando usar PARSE()

Apesar das várias desvantagens dessa função (desempenho, dependência de .NET, conversões limitadas de tipo de dados), ela também tem algumas vantagens e existem alguns cenários em que ela pode ser sua única opção. Por exemplo, ao fornecer uma data que inclua o nome do dia da semana, como sexta-feira, 20 de julho de 2018 .

Quando os outros retornam um erro

Aqui estão alguns exemplos em que PARSE() é a única função das três que pode converter o valor com sucesso sem gerar um erro.

Nestes exemplos, tentamos converter vários valores de string em uma data tipo de dados. No entanto, os valores de string que fornecemos incluem o nome do dia da semana. Isso causa problemas para CAST() e CONVERT() , mas PARSE() não tem 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 |
+------------+------------+------------+

Então PARSE() não tem nenhum problema com o formato da data que fornecemos.

CONVERTER()

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.

Então CONVERT() é incapaz de converter a string quando está em tal 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.

E CAST() retorna o mesmo erro.

Então, se você encontrar erros com as outras duas funções, tente PARSE() em vez de.

Especificando a cultura

Outro cenário em que você pode preferir usar o PARSE() função é ao especificar a cultura/idioma em que a string é fornecida. PARSE() tem um argumento opcional que permite especificar qual cultura usar. Se omitido, o idioma da sessão atual é usado.

Exemplo de inclusão da 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 |
+------------+------------+

Uma alternativa de cultura

Apesar do benefício de poder especificar a cultura com PARSE() , você tem a capacidade de alterar as configurações de idioma, o que significa que você pode obter o mesmo efeito ao usar CAST() ou CONVERT() .

Por exemplo, usando SET LANGUAGE us_english antes da consulta alterará as configurações de idioma atuais para us_english . Embora isso não permita que você especifique culturas diferentes na consulta (como no exemplo acima), isso afeta toda a consulta (e quaisquer consultas subsequentes).

Você também pode alterar as configurações de formato de data da mesma maneira. Por exemplo, SET DATEFORMAT mdy .

Aqui está um exemplo de como alterar a configuração de idioma antes de executar uma consulta com CAST() e CONVERT() :

Alemão:

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

br_português:

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

Lembre-se, ao fazer isso, você está alterando o ambiente de formato de idioma/data da sessão. Não se esqueça de trocá-lo de volta!