Início / dba / Perguntas / 338742
Accepted
questionto42
Asked: 2024-04-18 00:36:47 +0800 CST

Por que você deve sempre escrever “varchar” com o comprimento entre colchetes atrás dele? Freqüentemente, você obtém o resultado certo sem fazer isso

  • 772

"Muitas vezes, você obtém o resultado certo sem fazer isso."

Exemplo:

select CONVERT(varchar, getdate(), 112)

saídas

20240417

Eu vi isso em alguns lugares no Stack Exchange até encontrar um pequeno comentário que dizia ao leitor para não esquecer o comprimento entre colchetes. Afirmei que isso não é necessário se você definir o número do estilo para uma data e hora como esta. No entanto, agora tenho conhecimento suficiente para entender que "varchar nunca deve ficar sozinho", deve sempre ser escrito como algo como varchar(1234).

Quanto ao código acima, seria:

select CONVERT(varchar(8), getdate(), 112)

Se você olhar para ele, a saída é a mesma:

20240417

Um comentário abaixo foi ainda mais longe: char(8)deveria ser levado em consideração, já que

nenhum valor no estilo 112 será menor que 8 caracteres.

Por que você deve sempre escrever varchar com o comprimento entre colchetes atrás dele?

Links que levaram a esta pergunta

sql-server

2 respostas

  1. Best Answer

    Por que você ainda deve sempre escrever varchar com o comprimento entre colchetes atrás dele? Freqüentemente, você obtém o resultado certo sem fazer isso.

    Freqüentemente e sempre são duas coisas distintas.

    Exemplo:

    DECLARE @bin VARBINARY(200) = CAST('I have a lovely bunch of coconuts' AS varbinary(200))

select convert(varchar, @bin)

    A saída está faltandouts

    Eu tenho um lindo monte de casulos

    Isso se deve ao comportamento padrão :

    Quando n não é especificado em uma definição de dados ou em uma instrução de declaração de variável, o comprimento padrão é 1. Se n não for especificado ao usar as funções CASTe CONVERT, o comprimento padrão é 30.

    O que significa que qualquer coisa sem o número de bytes na definição é, na melhor das hipóteses, um bug eventual e resulta em perda de dados que, na pior das hipóteses, ninguém saberá.

    Além disso, observe que n in varchar(n)denota o número de bytes , não de caracteres:

    Um equívoco comum é pensar que com char(n) e varchar(n) , o n define o número de caracteres. No entanto, em char(n) e varchar(n) , o n define o comprimento da string em bytes (0 a 8.000). n nunca define o número de caracteres que podem ser armazenados. Isso é semelhante à definição de nchar(n) e nvarchar(n) .

    O equívoco acontece porque ao usar a codificação de byte único, o tamanho de armazenamento de char e varchar é n bytes e o número de caracteres também é n . No entanto, para codificação multibyte, como UTF-8 , intervalos Unicode mais altos (128 a 1.114.111) resultam em um caractere usando dois ou mais bytes.

    Por exemplo, em um contexto de agrupamento UTF8, o seguinte retorna 16:

    SELECT DATALENGTH('😎😎😎😎');

    Para armazenar essa string, você precisaria de pelo menos varchar(16), não varchar(4).

    • 8

  2. Não definir o comprimento de um varchar é comum, veja, por exemplo, Qual é o significado de 1/1/1753 no SQL Server? onde aparece a resposta mais votada SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)e ninguém reclamou depois de 13 anos e 171 mil visualizações. No entanto, ser difundido nem sempre significa ser bom.

    Por que você deveria colocar o comprimento atrás de cada varchar ?

    DECLARE @x varchar = CONVERT(varchar, getdate(), 112);
select @x
select CONVERT(varchar(8), getdate(), 112)

    Fora:

    20240417

    Achei que 8não seria necessário, pois o comprimento da saída poderia ser definido pelo style 112. No entanto, uma observação em Converter data aaaa-mm-dd em número inteiro AAAAMM por @AaronBertrand mostra:

    Se o estilo pudesse corrigir o comprimento, isso funcionaria conforme o esperado:
    DECLARE @x varchar = CONVERT(varchar, getdate(), 112);
    mas isso apenas retorna o caractere único 2 [em vez de 20240417] (e FORMAT também não pode salvá-lo ). O problema é que o SQL Server decidiu para você que isso é varchar(1)muito antes de você atribuir qualquer coisa, e algum número de estilo não mudará de ideia.

    E outra observação ainda pede que você faça, charem vez de varcharse você tiver certeza de que deve ter esse comprimento o tempo todo:

    Você sabe que quer 6 caracteres? Então digite char(6)em vez de varchar/* digitar é difícil */. Não há razão para NÃO ser explícito (ou usar varchar para comprimento fixo) e todos os motivos para ter cuidado.

    Seu blog Bad Habits to Kick: Varchar sem comprimento mostra em profundidade por que você deve escrever o comprimento entre colchetes atrás de any varchar:

    Como o atributo length é opcional, as pessoas parecem presumir que definir um varchar no T-SQL é como definir uma string em C#: "ele apenas se expandirá para qualquer tamanho que você inserir nele". O problema é que, se você não definir um comprimento, o SQL Server atribuirá um para você, e pode não ser o comprimento esperado. Em alguns cenários, será 1; em outros, 30.

    • -1

relate perguntas