Como as colunas longas afetam o desempenho e o uso do disco?

A resposta específica à sua pergunta (pelo menos para Oracle e provavelmente outros bancos de dados) é que o comprimento do campo não importa, apenas o comprimento dos dados. No entanto, isso não deve ser usado como um fator determinante sobre se deve ou não definir o campo em seu comprimento máximo permitido. Aqui estão algumas outras questões que você deve considerar antes de maximizar os tamanhos dos campos.

Formatação Qualquer ferramenta cliente que formate os dados com base no tamanho dos campos exigirá considerações especiais de formatação. O SQL*Plus da Oracle, por exemplo, exibe por padrão o tamanho máximo das colunas Varchar2, mesmo que os dados tenham apenas um caractere. Comparar…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

O comprimento do campo de dados incorretos fornece um mecanismo adicional para capturar/evitar dados incorretos. Uma interface não deve tentar inserir 3.000 caracteres em um campo de 100 caracteres, mas se esse campo for definido como 4.000 caracteres, pode ser. O erro não seria detectado no estágio de entrada de dados, mas o sistema pode ter problemas mais abaixo quando outro aplicativo tentar processar os dados e engasgar. Por exemplo, se você posteriormente decidir indexar o campo no Oracle, excederá o comprimento máximo da chave (dependendo do tamanho do bloco e da concatenação). Ver…

create index i1 on f1(a);

Memória Se o aplicativo cliente alocar memória usando o tamanho máximo, o aplicativo alocaria significativamente mais memória do que o necessário. Considerações especiais teriam que ser feitas para evitar isso.

Documentação O tamanho do campo fornece outro ponto de dados de documentação sobre os dados. Poderíamos chamar todas as tabelas t1, t2, t3, etc. e todos os campos f1, f2, f3, etc., mas especificando nomes significativos, entendemos melhor os dados. Por exemplo, se uma tabela de endereços de uma empresa com clientes nos EUA tiver um campo chamado Estado com dois caracteres, esperamos que a abreviação do estado de dois caracteres apareça nele. Por outro lado, se o campo tiver cem caracteres, podemos esperar que o nome completo do estado apareça no campo.

Dito isso, parece prudente estar preparado para a mudança. Só porque todos os nomes de produtos hoje cabem em 20 caracteres, não significa que sempre caberão. Não exagere e faça 1000, mas deixe espaço para uma expansão plausível.

Aqui está um bom ponto de partida para você.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Posso ter entendido mal sua pergunta original. Deixe-me ver se consigo encontrar alguns outros links para referência.

Aqui está uma boa referência sobre seleções de tipo de dados: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Mudar de varchar(20) para varchar(30) pode parecer algo pequeno, mas você precisa entender mais sobre como as estruturas de banco de dados funcionam para estar ciente dos possíveis problemas. Por exemplo, ir para varchar(30) pode levar você além do ponto de inflexão de suas colunas (se todos os 30 bytes forem usados), podendo ser armazenado em uma página (menos de 8060 bytes). Isso levará a um aumento no espaço em disco usado, uma diminuição no desempenho e até mesmo alguma sobrecarga adicional com seus logs de transação.

Aqui está um link para estruturas de banco de dados: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Aqui está um para divisões de página e log trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

Pensei em compartilhar outro ponto interessante, que encontrei em uma pergunta do Stack Overflow .

Resposta original por: Nick Kavadias

Uma razão para NÃO usar campos máximos ou de texto é que você não pode realizar reconstruções de índice online, ou seja, RECONSTRUIR COM ONLINE= ON, mesmo com o SQL Server Enterprise Edition.

Eu consideraria isso uma grande desvantagem ao adicionar colunas n/varchar(max) arbitrariamente e, de acordo com o site da MS, essa restrição contra reconstruções de índices online permanece no SQL Server 2008, 2008 R2 e Denali; portanto, não é específico do SQL Server 2005.

Em alguns casos, a quantidade de espaço alocada para um campo varchar afetará a quantidade de memória alocada para classificações na memória.

Achei as apresentações em SQLWorkshops.com instigantes, esta apresentação fala sobre um caso em que uma classificação para um pedido por está transbordando para tempdb porque não há memória suficiente sendo alocada para campos char/varchar.

http://webcasts2.sqlworkshops.com/webcasts.asp

Este webcast também foi apresentado como um artigo no seguinte site:

http://www.mssqltips.com/tip.asp?tip=1955

Observe nesta apresentação que a coluna que está sendo classificada não é a coluna char/varchar, mas a quantidade de espaço alocado para a coluna varchar na memória faz diferença no desempenho da consulta em alguns casos.

DEFINIR ANSI_PADDING ATIVADO?

Você acaba com muitos espaços em branco à direita ...

Importa apenas em relação ao espaço em disco e ao comprimento dos caracteres. É claro que a pesquisa em tipos de dados char e índices nesses tipos de dados agirão mais lentamente que inteiros, mas isso é outra discussão.

O tipo de dados Varchar é um tipo de dados "variável", portanto, se você configurar um limite de varchar (500), esse será o comprimento máximo de caracteres para esse campo. O comprimento mínimo pode ser entre 0 e 500. Por outro lado, o espaço em disco reivindicado será diferente para campos de 10, 30 ou 500 caracteres.

Fiz algumas vezes um teste para dados do tipo varchar (800) e para valores nulos tive 17 bytes usados, e para cada caractere inserido adicionava mais um byte. Por exemplo, uma string de 400 caracteres tinha 417 bytes usados ​​no disco.

Eu não acho que haja qualquer diferença entre tabelas criadas com colunas de varchar(20) ou varchar((8000), desde que o comprimento máximo real seja <= 20.

Por outro lado, em alguns casos, dar aos usuários a possibilidade de armazenar strings mais longas pode incentivá-los a fazê-lo.