Quais são as conseqüências da configuração do varchar (8000)?

22

Como o varchar ocupa um espaço em disco proporcional ao tamanho do campo, existe alguma razão pela qual nem sempre devemos definir varchar como o máximo, por exemplo, varchar(8000)no SQL Server?

Na tabela create, se eu vir alguém fazendo varchar(100), devo dizer que não, você está errado, deve fazer varchar(8000)?

sql-server varchar

— Aleksandr Levchuk
fonte

Acho que precisamos diferenciar aqui entre o uso na tabela create e o uso nas declarações de parâmetros dos procedimentos armazenados. Para a segunda interpretação, veja minha pergunta dba.stackexchange.com/questions/1772/…

— bernd_k

18

O comprimento é uma restrição nos dados (como CHECK, FK, NULL, etc.)
Desempenho quando a linha exceder 8060 bytes
Não pode ter restrição ou índice exclusivo (a largura da coluna da chave deve ser <900)
O padrão é SET ANSI PADDING ON = potencial para muitos espaços à direita serem armazenados
O SQL Server assumirá que o comprimento médio é de 4000 para operações de classificação, alocando memória com base nisso (precisa encontrar um link para fazer backup disso, mas me enferruja enquanto eu faço :-)

Resumo: não faça isso.

— gbn
fonte

Desempenho quando a linha exceder 8060 bytes . Isso se refere aos bytes usados reais e não aos bytes máximos permitidos?

— 18118 bernd_k

@bernd_k: 8060 = maior quantidade de dados para uma linha que cabe em uma única página 8192. Incluir sobrecarga de linha. Restante (132 bytes) = sobrecarga da página

— gbn

Isso significa que o desempenho diminui quando o tamanho maior é realmente usado, não pelo simples fato de que é permitido.

— 5111 bernd_k

@bernd_k: qualquer queda no desempenho é causada por 1. alocação de memória para classificações etc. 2. Estouro de linha (> 8060 bytes). O fato de ter 10 caracteres em cada varchar (8000) é irrelevante até que essas condições sejam atendidas (o SQL avisa sobre possíveis erros posteriormente para chaves de índice)

— gbn

Classificar uma tabela com uma coluna varchar (100) preenchida com campos de 100 bytes vale outra pergunta, porque a classificação assume em média 50 caracteres?

— 5111 bernd_k

7

Supondo que você esteja se referindo ao SQL Server, posso pensar em um.

Há um limite para o tamanho (8K) de uma linha em uma tabela e o SQL permite definir campos varchar que teoricamente poderiam exceder esse limite. Portanto, o usuário poderá obter erros se colocar muitos dados no campo relacionado a isso.

A partir do SQL 2K8, você pode exceder esse limite, mas há implicações no desempenho .

Além disso, há toda a verificação de razoabilidade de limitar o tamanho ao que você espera que os dados sejam. Se você deseja um campo de tamanho ilimitado, por que não usar texto ou ntext?

— JohnFx
fonte

para que os tipos de dados texto e ntext sejam armazenados de uma maneira que não afete o desempenho?

— Chad

Esses tipos não contribuem muito para o limite de tamanho de linha de 8K em uma tabela porque os dados reais são armazenados em uma tabela separada sob as capas, em vez de alinhados com o restante das colunas. Ainda há um impacto no desempenho, mas por diferentes razões. Há também limitações ao apoio recurso sobre estes campos quando comparado com varchar e nvarchar

— JohnFx

text e ntext foram descontinuados em favor de varchar (max).

— Phil Helmer

3

Certamente depende de quais informações estão sendo armazenadas no campo?

Algumas coisas terão um comprimento máximo por várias razões e, se tiver que haver um comprimento máximo, esse deverá ser o comprimento do seu campo.

Se teoricamente não houver comprimento máximo, eu questionaria por que o varchar seria usado.

— Toby
fonte

3

No contexto dos bancos de dados Oracle, aprendi que sempre usar o menor tamanho de campo para colunas de banco de dados tem uma armadilha.

Ao mover dados por meio de exportação e importação de um banco de dados com agrupamento de byte único para outro com agrupamento de vários bytes (como Oracle XE), o comprimento em bytes pode aumentar e a importação dos dados para as tabelas criadas pela importação falha. Obviamente, a Oracle tem a opção de definir o comprimento do varchar2 como char ou como byte.

O que quero dizer aqui é que nem sempre é aconselhável definir um campo sempre o menor possível. Tenho visto muitas tabelas de alterações para aumentar o campo posteriormente (causado por requisitos alterados).

Ter 20% - 100% de campo não utilizado é uma opção discutível aqui.

— bernd_k
fonte