¿Cuál es la diferencia entre el tipo de datos text
y los tipos de datos character varying
(varchar
)?
Según la documentación
Si se utiliza character varying sin especificador de longitud, el tipo acepta cadenas de cualquier tamaño. Este último es una extensión de PostgreSQL.
y
Además, PostgreSQL proporciona el tipo text, que almacena cadenas de cualquier longitud. Aunque el tipo text no está en el estándar SQL, varios otros sistemas de gestión de bases de datos SQL también lo tienen.
Entonces, ¿cuál es la diferencia?
No hay ninguna diferencia, bajo el capó todo es varlena
(matriz de longitud variable).
Consulte este artículo de Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/
Un par de puntos destacados:
Para resumirlo todo:
- char(n) - toma demasiado espacio cuando se trata de valores más cortos que
n
(los rellena an
), y puede llevar a errores sutiles debido a la adición de espacios de arrastre espacios, además de que es problemático cambiar el límite- varchar(n) - es problemático cambiar el límite en un entorno real (requiere un bloqueo exclusivo mientras se altera la tabla)
- varchar - igual que el texto
- text - para mí un ganador - sobre (n) tipos de datos porque carece de sus problemas, y sobre varchar - porque tiene nombre distinto
El artículo hace pruebas detalladas para demostrar que el rendimiento de las inserciones y selecciones para los 4 tipos de datos es similar. También examina detalladamente las formas alternativas de restringir la longitud cuando es necesario. Las restricciones basadas en funciones o en dominios proporcionan la ventaja de aumentar instantáneamente la restricción de longitud, y sobre la base de que la disminución de una restricción de longitud de cadena es poco frecuente, depesz concluye que una de ellas suele ser la mejor opción para un límite de longitud.
Como "Tipos de caracteres" en la documentación señala, varchar(n)
, char(n)
, y texto
son todos almacenados de la misma manera. La única diferencia es que se necesitan ciclos extra para comprobar la longitud, si se da una, y el espacio y tiempo extra que se requiere si se necesita relleno para char(n)
.
Sin embargo, cuando sólo necesita almacenar un único carácter, hay una ligera ventaja de rendimiento al utilizar el tipo especial `"char"(mantenga las comillas dobles - son parte del nombre del tipo). Se obtiene un acceso más rápido al campo, y no hay sobrecarga para almacenar la longitud.
Acabo de hacer una tabla con 1.000.000 de "char" aleatorios elegidos del alfabeto en minúsculas. Una consulta para obtener una distribución de frecuencias (
select count(*), field ... group by field) tarda unos 650 milisegundos, frente a unos 760 en los mismos datos utilizando un campo
text`.
En el manual de PostgreSQL
No hay ninguna diferencia de rendimiento entre estos tres tipos, aparte de un mayor espacio de almacenamiento cuando se utiliza el tipo con relleno en blanco, y unos pocos ciclos de CPU adicionales para comprobar la longitud cuando se almacena en una columna con restricciones de longitud. Mientras que character(n) tiene ventajas de rendimiento en algunos otros sistemas de bases de datos, no existe tal ventaja en PostgreSQL; de hecho, character(n) suele ser el más lento de los tres debido a sus costes adicionales de almacenamiento. En la mayoría de las situaciones se debería utilizar texto o caracteres variados en su lugar.
Yo suelo usar text
Referencias: http://www.postgresql.org/docs/current/static/datatype-character.html