Qual tamanho escolher para uma coluna (n)varchar?

StackOverflow https://stackoverflow.com/questions/1261441

Pergunta

Em um discussão ligeiramente acalorada sobre TDWTF surgiu uma dúvida sobre o tamanho das colunas varchar em um banco de dados.

Por exemplo, pegue um campo que contenha o nome de uma pessoa (apenas nome, sem sobrenome).É muito fácil perceber que não demorará muito.A maioria das pessoas tem nomes com menos de 10 caracteres e poucos são os que têm mais de 20.Se você fizesse sua coluna, digamos, varchar(50), ela definitivamente conteria todos os nomes que você encontraria.

No entanto, para a maioria dos SGBDs, não faz diferença em tamanho ou velocidade se você cria um varchar(50) ou um varchar(255).

Então, por que as pessoas tentam fazer com que suas colunas sejam tão pequenas quanto possível?Eu entendo que em alguns casos você pode querer colocar um limite no comprimento da string, mas na maioria das vezes não é assim.E uma margem maior só será benéfica se houver um caso raro de uma pessoa com um nome extremamente longo.

Adicionado: As pessoas querem referências à afirmação sobre “nenhuma diferença de tamanho ou velocidade”.OK.Aqui estão eles:

Para MSSQL: http://msdn.microsoft.com/en-us/library/ms176089.aspx

O tamanho do armazenamento é o comprimento real dos dados inseridos + 2 bytes.

Para MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

L + 1 bytes se os valores da coluna exigirem de 0 a 255 bytes, L + 2 bytes se os valores exigirem mais de 255 bytes

Não consigo encontrar documentação para Oracle e não trabalhei com outro SGBD.Mas não tenho motivos para acreditar que seja diferente aí.

Foi útil?

Solução

Eu só posso falar pelo Oracle. A Varchar2 (50) e um VARCHAR2 (255) ocupam exatamente a mesma quantidade de espaço e executam de forma idêntica, se você inserir o valor 'Smith'.

No entanto, a razão pela qual geralmente não é uma boa idéia declarar todas as suas colunas textuais, pois o VARCHAR2 (4000) é que o comprimento da coluna é, efetivamente, outra restrição. E as restrições são a implementação do banco de dados das regras de negócios, portanto, elas são definitivamente algo que deve ser definido no lado do banco de dados.

Como um exemplo. Você define uma restrição de verificação em uma coluna para que os valores que ele possa aceitar sejam apenas 'y' e 'n'. Isso salva sua aplicação de ter que lidar com 'y' e 'n' ou mesmo '1' e '0'. A restrição de verificação garante que seus dados estão em conformidade com os padrões esperados. O código do seu aplicativo pode fazer suposições válidas sobre a natureza dos dados com os quais deve lidar.

A definição de comprimento da coluna está no mesmo barco. Você declara que algo é um Varchar2 (10) porque não deseja que ele aceite uma entrada de 'ABC123ZYX456' (por qualquer motivo!)

Na Austrália, defino colunas estaduais como um Varchar2 (3), porque não quero que as pessoas digitem em 'Nova Gales do Sul' ou 'Austrália do Sul'. A definição da coluna praticamente os obriga a serem inseridos como 'NSW' e 'SA'. Nesse sentido, um VARCHAR2 (3) é quase uma restrição de verificação que realmente especifica um check -in ('nsw', 'sa', 'vic' etc.) restrição.

Em resumo, os comprimentos adequados da coluna são uma maneira de codificar regras de negócios. Eles são outra forma de restrição. Eles trazem todas as vantagens das restrições (e sofrem de muitas das mesmas desvantagens). E eles garantem, em pequena medida, um grau de 'limpeza de dados' com a qual as restrições "adequadas" também ajudam.

Também não compro o argumento de que é melhor manter esse tipo de coisa no aplicativo cliente, porque é mais fácil mudar lá. Você tem 20.000 pessoas usando um aplicativo, ou seja, 20.000 atualizações. Você tem um banco de dados, essa é uma atualização. O argumento 'mais fácil de alterar o aplicativo do cliente', se verdadeiro, significaria potencialmente que o banco de dados é tratado como um balde de bit gigante, com toda a lógica inteligente sendo tratada no código do cliente. É uma grande discussão, mas como todos os RDBMSs permitem definir restrições e assim por diante no próprio banco de dados, fica bem claro que há pelo menos um caso que vale a pena ser argumentado que essa lógica fundamental pertence ao back -end.

Outras dicas

Eu ouvi o otimizador de consulta faz leve em consideração o comprimento do varchar, embora não consiga encontrar uma referência.

Definir um comprimento varchar ajuda a comunicar a intenção.Quanto mais restrições forem definidas, mais confiáveis ​​serão os dados.

Então, por que as pessoas tentam tornar suas colunas o menor possível? Não acredito em torná -los o menor possível, mas em dimensioná -los adequadamente. Algumas razões para tornar (n) varchars menores e não maiores:

1) Com um campo maior, todos os clientes que usam o banco de dados devem poder lidar com o tamanho completo. Por exemplo, pegue um sistema que possua um endereço dos Estados Unidos com 255 caracteres por cada campo: (semelhante ao TDWTF que você faz referência, acredito.)

  • Primeiro nome
  • Sobrenome
  • Endereço Linha 1
  • endereço linha 2
  • Cidade
  • Estado
  • Código postal

Agora, as telas de entrada de dados precisarão permitir e mostrar 255 caracteres por campo. Não é difícil, mas é improvável que fique bem com as faturas de impressão de campos maiores, você precisará de lógica de quebra de linha para lidar com os campos grandes. Dependendo da ferramenta, não tão difícil.

Mas eu não gostaria do problema de formatar o endereço para um envelope que poderia ter 255 caracteres para cada um desses campos ou apenas qualquer um desses campos. Você vai truncar se o campo for muito longo para caber? Ótimo alguém tem linha de endereço 1 de "Número do número da casa Número de streat ... blá blá blá ... Número do apartamento 111". E você amarrará o número importante do apartamento. Você vai embrulhar? Quantos? E se você simplesmente não conseguir encaixá -lo na pequena caixa de espaço no envolvimento? Levantar uma exceção e ter alguém para a mão?

2) Enquanto 10 caracteres de dados mantidos em um VARCHAR (50) versus Varchar (255) não afetam o tamanho ou a velocidade, permitindo que 255 caracteres permitam que mais espaço seja obtido. E se todos os campos forem tão grandes, você poderá atingir limites de tamanho no SQL Server 2000. (Eu não li em 2005 e 2008 para ver se eles podem lidar com linhas maiores de uma página.) E com o Oracle os tamanhos maiores permitem linha Correção para acontecer se alguém realmente usar todos os personagens disponíveis.

3) Os índices têm limites de tamanho mais rígido do que as páginas de folhas. Você pode impedir os índices, especialmente os índices compostos, se criar seus Varchars muito grandes.

Por outro lado, tenho uma longa linha 1 para o meu endereço e fiquei frustrada com sites que não permitem que a coisa completa seja digitada.

Uma distinção importante está entre especificar um limite arbitrariamente grande [por exemplo VARCHAR(2000)], e usando um tipo de dados que não requer um limite [por exemplo VARCHAR(MAX) ou TEXT].

PostgreSQL bases todo o seu comprimento fixo VARCHARestá em seu ilimitado TEXT tipo e decide dinamicamente por valor Como armazenar o valor, incluindo armazená-lo fora da página. O especificador de comprimento neste caso é realmente apenas uma restrição, e seu uso é realmente desencorajado. (Ref)

Outros DBMSs exigem que o usuário selecione se exigir "ilimitado", fora da página, armazenamento, geralmente com um custo associado em conveniência e/ou desempenho.

Se houver uma vantagem em usar VARCHAR(<n>) sobre VARCHAR(MAX) ou TEXT, segue -se que você deve selecionar um valor para <n> Ao projetar suas mesas. Supondo que exista alguma largura máxima de uma linha de tabela ou entrada de índice, as seguintes restrições devem aplicar:

  1. <n> deve ser menor ou igual a <max width>
  2. E se <n> = <max width>, a tabela/índice pode ter apenas 1 coluna
  3. Em geral, a tabela/índice só pode ter <x> colunas onde (em média) <n> = <max width> / <x>

É, portanto não o caso que o valor de <n> atua apenas como uma restrição e a escolha de <n> deve fazer parte do design. (Mesmo que não haja limite rígido no seu DBMS, pode haver razões de desempenho para manter a largura dentro de um determinado limite.)

Você pode usar as regras acima para atribuir um máximo valor de <n>, com base na arquitetura esperada da sua tabela (levando em consideração o impacto de mudanças futuras). No entanto, faz mais sentido definir o mínimo valor de <n>, com base no esperado dados em cada coluna. Provavelmente, você se expandirá para o "número redondo" mais próximo - por exemplo, você sempre usará VARCHAR(10), VARCHAR(50), VARCHAR(200), ou VARCHAR(1000), qualquer que seja o melhor ajuste.

A resposta simples a isso, na minha opinião, é o fato de que você não pode usar essa coluna como uma chave de índice, se precisar de qualquer indexação, é basicamente forçado a usar o FullText ... Isso se com relação ao uso de uma coluna Varchar (Max). De qualquer forma, as colunas de 'tamanho certo' fazem muito sentido sempre que você [pode] querer aplicar qualquer indexação; A atualização de colunas de comprimento variável pode ser uma manobra dispendiosa, pois não são feitas no local e podem/causará alguma quantidade de fragmentação.

Tudo com relação ao MS SQ-Server.

Responderei sua pergunta com uma pergunta: se não há diferença para os DBMs entre um Varchar (50) e um Varchar (255), por que os DBMs permitiriam fazer uma distinção? Por que um DBMS simplesmente não diria "Use Varchar para caracteres até XXX e texto/clob/etc. para qualquer coisa sobre isso". Claro, talvez a Microsoft/Oracle/IBM possa manter a definição de comprimento por razões históricas, mas e o DBMS 'como o MySQL, que tem vários back-ends de armazenamento- por que todos implementam comprimentos de coluna de caracteres definíveis?

Se você vai imprimir etiquetas, geralmente deseja que a string não tenha mais de 35 caracteres. É por isso que você deseja algum controle sobre o tamanho do Varchar que você usará para aceitar as linhas que serão usadas para imprimir rótulos.

Se você permitir que o comprimento dos dados seja superior a 255 e alguém vincular os dados através do MS Access, os dados não poderão ser usados ​​para unir tabelas (entram como um campo de memorando).Se os dados forem exportados para Excel serão limitados a 255 caracteres por campo.A compatibilidade com outros programas deve ser considerada ao criar conjuntos de dados.
O controle de qualidade de dados trata do controle dos dados que entram em seu ambiente.O que você precisa armazenar com mais de 255 caracteres?Há momentos em que os dados precisam ter mais de 255 caracteres, mas devem ser espaçados e devem ser usados ​​como informações suplementares de apoio para um campo que pode ser usado para análise

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top