Início / dba / Perguntas / 20974
Accepted
Daniel Serodio
Asked: 2012-07-17 09:31:57 +0800 CST

Devo adicionar um limite de comprimento arbitrário às colunas VARCHAR?

  • 772

De acordo com a documentação do PostgreSQL , não há diferença de desempenho entre VARCHAR, VARCHAR(n)e TEXT.

Devo adicionar um limite de comprimento arbitrário a uma coluna de nome ou endereço ?

Edit: Não é um dupe de:

Eu sei que o CHARtipo é uma relíquia do passado e estou interessado não apenas no desempenho, mas em outros prós e contras, como Erwin afirmou em sua incrível resposta.

postgresql performance

4 respostas

  1. Best Answer

    A resposta é não .

    Conselhos relacionados no Postgres Wiki.

    Não adicione um modificador de comprimento varcharse você não precisar dele. (Na maioria das vezes, não.) Use apenas textpara todos os dados de caracteres. Faça isso varchar(tipo SQL padrão) sem modificador de comprimento se você precisar permanecer compatível com RDBMS que não possui textum tipo de cadeia de caracteres genérico.

    O desempenho é quase o mesmo, texté um pouco mais rápido em raras situações , e você salva os ciclos para a verificação do comprimento. Relacionado:

    Se você realmente precisa impor um comprimento máximo, varchar(n)é uma escolha válida, mas eu ainda consideraria textcom uma CHECKrestrição como:

    ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);

    Você pode modificar ou descartar tal restrição a qualquer momento sem ter que mexer na definição da tabela e objetos dependentes (visualizações, funções, chaves estrangeiras, ...). E você pode impor outros requisitos na (mesma) restrição.

    Modificadores de comprimento usados ​​para causar problemas como este ou este ou este ...

    O PostgreSQL 9.1 introduziu um novo recurso para aliviar um pouco a dor. As notas de lançamento:

    Permitir ALTER TABLE ... SET DATA TYPEevitar reescritas de tabela em casos apropriados (Noah Misch, Robert Haas)

    Por exemplo, converter uma varcharcoluna em texto não requer mais uma reescrita da tabela. No entanto, aumentar a restrição de comprimento em uma varcharcoluna ainda requer uma reescrita da tabela.

    Mais problemas com varchar(n)foram corrigidos em versões posteriores.

    • 98

  2. Se você vir o limite de comprimento como um tipo de restrição de verificação para certificar-se de validar os dados, adicione um sim. Na verdade, você pode querer não usar uma definição de comprimento, mas uma restrição de verificação real, para tornar a alteração do limite mais rápida.

    Para alterar (aumentar) um limite de comprimento você precisa executar um ALTER TABLEque pode levar muito tempo para terminar (devido a uma possível reescrita da tabela) durante o qual é necessário um bloqueio de tabela exclusivo.

    Alterar (ou seja, descartar e recriar) uma restrição de verificação é uma operação muito breve e requer apenas a leitura dos dados da tabela, não altera nenhuma linha. Então, isso será muito mais rápido (o que, por sua vez, significa que o bloqueio de tabela exclusivo será mantido por um período muito menor de tempo).

    Durante a operação não há diferença alguma entre a text, a varcharou a varchar(5000)coluna.

    • 14

  3. A questão é especificamente se adicionar um limite de comprimento arbitrário às colunas VARCHAR?

    Para isso, a resposta é simplesmente "não". Não há nada que possa justificar a adição de um limite arbitrário como você faria em bancos de dados inferiores que suportam varchar(max)ou usam convenções como varchar(255). No entanto, se a especificação abordar um limite, acho que a resposta se torna muito mais complexa, especialmente nas versões modernas do PostgreSQL. E, para isso, eu me inclinaria para o SIM .

    Na minha opinião, o limite é uma escolha sábia se a especificação exigir. Especialmente para cargas de trabalho mais razoáveis. Se não for por nenhum outro motivo, para preservar os metadados.

    Da minha resposta aqui, indexe o desempenho para CHAR vs VARCHAR (Postgres) , onde abordo o valor dos metadados.

    Se eu encontrasse uma especificação que tivesse chaves de texto de comprimento variável que fossem significativas e que eu confiasse para ter um comprimento máximo constante, eu também usaria varchar. No entanto, não consigo pensar em nada que se encaixe nesses critérios.

    • 2

  4. Parece que pode haver alguma diferença de desempenho se VARCHARfor usado regularmente para armazenar strings muito grandes, já que "strings longas são compactadas pelo sistema automaticamente" e "valores muito longos também são armazenados em tabelas de fundo". Teoricamente, isso significaria que um grande volume de solicitações para um campo de string muito longo seria mais lento do que para um campo de string curto. Você provavelmente nunca terá esse problema, já que nomes e endereços não serão muito longos.

    No entanto, dependendo de como você está usando essas strings fora do banco de dados, convém adicionar um limite prático para evitar o abuso do sistema. Por exemplo, se você estiver exibindo o nome e o endereço em um formulário em algum lugar, talvez não seja possível exibir um parágrafo inteiro de texto no campo "nome", portanto, faria sentido limitar a coluna de nome a algo como 500 personagens.

    • 1

relate perguntas