Usando tamanho da coluna muito maior que o necessário


16

Estou criando um banco de dados do SQL Server com outra pessoa. Uma das tabelas é pequena (6 linhas) com dados que provavelmente permanecerão constantes. Há uma possibilidade remota de que uma nova linha seja adicionada. A tabela é mais ou menos assim:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Estou analisando o comprimento do caractere dessa namecoluna e acho que seus valores provavelmente nunca serão maiores que, digamos, 32 caracteres, talvez nem maiores que 24. Existe alguma vantagem em alterar essa coluna para, por exemplo varchar(32)?

Além disso, existe alguma vantagem em manter os tamanhos de coluna padrão em múltiplos de 4, 8, 32 etc.?

Respostas:


15

O SQL Server usa comprimentos de coluna ao alocar memória para processamento de consultas. Portanto, sim, resumindo, você sempre deve dimensionar as colunas adequadamente para os dados.

As alocações de memória são baseadas no número de linhas retornadas pela consulta multiplicadas pela metade do comprimento declarado da coluna.

Dito isto, neste caso em que você tem 6 linhas, provavelmente não deseja otimizar demais prematuramente. A menos que você junte esta tabela a outra com milhões de linhas, não haverá uma grande diferença entre um varchar (24) e um varchar (32), ou mesmo um varchar (128).

Sua segunda pergunta é sobre o alinhamento dos comprimentos das colunas em múltiplos binários. Isso não é necessário, pois o SQL Server armazena todos os dados em páginas de 8 KB, independentemente do comprimento de cada coluna.


14

Com 6 linhas, não, não haverá benefício observável. Essa tabela inteira caberá em uma única página, diminuindo o espaço potencial máximo que você usará nessa página enquanto ainda ocupa a página inteira, na verdade não é diferente em todos os aspectos práticos.

Em tabelas maiores, porém, o dimensionamento correto é crucial. O motivo é que as estimativas de memória serão baseadas na suposição de que todo valor será preenchido em 50%. Portanto, se você tiver varchar (128), todo valor deverá ocupar 64 bytes, independentemente dos dados reais, portanto, a concessão de memória será 64b * número de linhas. Se todos os valores tiverem 32 caracteres ou menos, torná-lo um varchar (64) ou mesmo varchar (32) provavelmente é uma escolha melhor. Se uma grande porcentagem de valores estiver próxima ou dentro do limite, você pode até argumentar que o carvão reduza a volatilidade.

Quanto aos benefícios de ter comprimentos de cadeia limitados às potências de 2, não acho que no hardware de hoje alguém possa demonstrar vantagens óbvias.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.