Qual'é a diferença entre o tipo de dados "texto" e o tipo de dados "variação de caracteres" (varchar
)?
De acordo com a documentação.
Se caracteres variáveis forem utilizados sem especificador de comprimento, o tipo aceita cordas de qualquer tamanho. Esta última é uma extensão do PostgreSQL.
e
Além disso, o PostgreSQL fornece o tipo de texto, que armazena cordas de qualquer comprimento. Embora o tipo de texto não esteja no padrão SQL, vários outros sistemas de gerenciamento de banco de dados SQL também o possuem.
Então qual'é a diferença?
Não há diferença, sob o capô ele's all varlena
(matriz de comprimento variável).
Confira este artigo do Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/
Um par de destaques:
Para resumir tudo:
- char(n) - ocupa muito espaço quando se lida com valores mais curtos do que
n
(almofada-os paran
), e pode levar a erros subtis por causa da adição de trailing espaços, além disso, é problemático alterar o limite- varchar(n) - it's problemático para alterar o limite em ambiente vivo (requer bloqueio exclusivo enquanto se altera a tabela)
- varchar - tal como o texto
- texto - para mim um vencedor - sobre (n) tipos de dados porque não tem os seus problemas, e sobre varchar - porque tem nome distinto
O artigo faz testes detalhados para mostrar que o desempenho das inserções e seleções para todos os 4 tipos de dados são similares. Ele também analisa detalhadamente formas alternativas de restringir o comprimento quando necessário. Restrições baseadas em funções ou domínios fornecem a vantagem de aumentar instantaneamente a restrição de comprimento, e com base no fato de que diminuir uma restrição de comprimento de cadeia é raro, depesz conclui que uma delas é geralmente a melhor escolha para um limite de comprimento.
As "Tipos de caracteres" na documentação aponta, varchar(n)
, char(n)
, e text' são todos armazenados da mesma forma. A única diferença é que são necessários ciclos extras para verificar o comprimento, se um for dado, e o espaço e tempo extras necessários se o preenchimento for necessário para
char(n)`.
No entanto, quando você só precisa armazenar um único caractere, há uma ligeira vantagem de desempenho ao utilizar o tipo especial "char"
(mantenha as aspas duplas - they're parte do nome do tipo). Você tem acesso mais rápido ao campo, e não há nenhuma sobrecarga para armazenar o comprimento.
Acabei de fazer uma tabela de 1.000.000 de "char"
escolhida a partir do alfabeto de minúsculas. Uma consulta para obter uma distribuição de freqüência (select count(*), field ... group by field') leva cerca de 650 milisegundos, versus cerca de 760 nos mesmos dados utilizando um campo
texto'.
No manual do PostgreSQL
Não há diferença de desempenho entre estes três tipos, além do aumento do espaço de armazenamento quando se usa o tipo de bloco em branco, e alguns ciclos extras de CPU para verificar o comprimento ao armazenar em uma coluna com restrições de comprimento. Enquanto o character(n) tem vantagens de performance em alguns outros sistemas de banco de dados, não existe tal vantagem no PostgreSQL; de fato, o character(n) é normalmente o mais lento dos três devido aos seus custos adicionais de armazenamento. Na maioria das situações, texto ou caracteres variáveis devem ser utilizados em seu lugar.
Eu normalmente uso texto
Referências: http://www.postgresql.org/docs/current/static/datatype-character.html