Existe algum motivo para usar tamanhos VARCHAR arredondados para um deslocamento de 128/256/4096 bytes?

Nos esquemas do banco de dados, costumo notar que os tamanhos do VARCHAR são arredondados para os desvios de bytes 128/256 ou 4096. Eu já fiz isso antes também, e a ideia por trás disso era provavelmente algo com eficiência.

No entanto, ainda existe uma razão válida para fazer isso hoje em dia? Atualmente, uso '50', '100' ou '200' como tamanhos VARCHAR atualmente, pois eles são mais naturais e geralmente também são mostrados em verificações de validação para o usuário.

A única explicação racional em que posso pensar seria: Se o DBMS armazena os valores de uma coluna sequencialmente e os tamanhos não são arredondados para uma potência de 2, então alguns elementos podem ter que ser "divididos" em duas páginas no disco rígido (por exemplo, os primeiros 10 bytes na página ne os próximos 40 bytes na página n + 1), que em alguns casos podem levar a duas leituras do disco rígido em vez de uma.

O mais provável é o argumento de @Jan Hudec que, muitos programadores pensam em "128" ou "256" como "números agradáveis", o que os torna escolhas mais naturais do que números ímpares como 137, 19 ou 100.

Em geral, não há razão para esses comprimentos de coluna. Não haverá melhoria no desempenho de uma coluna varchar (100) versus uma coluna varchar (128).

No entanto, eu verificaria novamente o sistema de banco de dados que você está usando para obter mais esclarecimentos sobre restrições e outras advertências específicas do fornecedor.

Por exemplo, aqui está um bom exemplo de uma restrição do sistema de banco de dados para o SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

O comprimento total da linha é mais importante que o comprimento das colunas individuais.

Não me lembro se era um DBMS ou um compilador, mas lembro (há muito tempo) que aprendi a usar potências de 2 para comprimentos de matriz e coluna. Havia uma justificativa de que era "mais rápido" por causa da implementação poder mudar de bits. Se é mais verdade é uma questão em aberto. Alguém tem alguma idéia sobre se ainda é válido?

BTW eu mudei as larguras das colunas para o número uniforme b / c, é estranho dizer aos usuários que o limite de caracteres é de 256 caracteres.

E alguns bancos de dados muito antigos limitaram você a 256 colunas de largura de char.

Provavelmente, isso realmente não importa, pois você só veria alguma eficiência de armazenamento se o tamanho de toda a sua linha fosse uma potência de 2. É possível que a aderência com potências de 2 aumentasse a probabilidade de o tamanho da sua linha funcionaria com uma potência de dois (já que a maioria dos tipos de dados nativos tendem a ter tamanho de potência 2 [dependendo do banco de dados]), mas eu não a tornaria uma regra rígida.

Pode fazer mais sentido se você estiver trabalhando com colunas grandes (4K ou maiores), pois elas podem ser armazenadas separadamente e dimensionadas para caberem em um bloco de armazenamento (seja qual for o uso do banco de dados para armazenamento em disco) você alguma coisa.

Embora eu não esteja familiarizado com todos os sistemas DBMS, a menor unidade de armazenamento "físico" no Oracle é um "bloco" que, por padrão, tem 2 KB de tamanho. A prática de dimensionar suas colunas em potências de dois faz parte de uma prática maior de dimensionar suas linhas para caber adequadamente nos blocos de armazenamento. O dimensionamento de suas colunas para que uma linha exija um byte a mais do que o tamanho do bloco exigiria a alocação de dois blocos e sua linha também abrangeria dois blocos, tornando a leitura, a inserção e a digitalização mais demoradas do que se você pudesse ajustar cada bloco de cada linha (e só tem uma linha em cada bloco). Essa, pelo menos, é a razão histórica para isso. Atualmente, a maioria das pessoas considera essa prática uma subotimização.