tips - utilizar indices en consultas sql

¿Alguna desventaja de utilizar el tipo de datos "texto" para almacenar cadenas?

Question

Según la documentación de Postgres , admiten 3 tipos de datos para datos de caracteres:

character varying(n), varchar(n) variable-length with limit
character(n), char(n) fixed-length, blank padded
text variable unlimited length

En mi aplicación, encontré algunos escenarios desagradables en los que las consultas de inserción / actualización fallaron, ya que el texto deseado para insertar excedía el límite de varchar(n) o char(n) .

Para tales casos, basta cambiar el tipo de datos de tales columnas para text .

Mis preguntas son:
Si generalizamos y cambiamos el tipo de datos de cada columna de almacenamiento de caracteres a text , ¿hay alguna desventaja en términos de rendimiento / memoria?
Si una columna con text tipo de datos almacena 10 o menos caracteres cada vez, ¿debería varchar(10) text o varchar(10) ?
Si voy por text ¿cuál es el inconveniente?

Answer 1

Desde la página a la que vinculó:

"No hay diferencia de rendimiento entre estos tres tipos, aparte de un mayor espacio de almacenamiento cuando se utiliza el tipo de relleno en blanco, y algunos ciclos de CPU adicionales para verificar la longitud cuando se almacena en una columna de longitud limitada. Mientras que el carácter (n) tiene rendimiento ventajas en algunos otros sistemas de bases de datos, no existe tal ventaja en PostgreSQL, de hecho, el carácter (n) suele ser el más lento de los tres debido a sus costos de almacenamiento adicionales. En la mayoría de los casos, se debe usar texto o carácter variable ".

No parece haber ningún inconveniente de usar el tipo de datos de text en Postgres.

Sin embargo, debe considerar si realmente desea permitir que se almacenen enormes textos en la base de datos. Mantenerlo como varchar pero con un límite superior lo protegería de almacenar inadvertidamente grandes cantidades de datos en la base de datos.

Answer 2

Todos los tipos de datos que mencionas usan la misma representación interna ( struct varlena moderadamente famosa)

Los tipos de datos CHAR y VARCHAR simplemente agregan verificaciones de longitud a esto, y (en el caso de CHAR ), tienen una semántica de espacio-relleno diferente.

Puedes usar TEXT manera segura donde nada de lo anterior sea importante para tu lógica.

Answer 3

En general, no hay inconvenientes en el uso del text en términos de rendimiento / memoria. Por el contrario: el text es el óptimo. Otros tipos tienen desventajas más o menos relevantes. @Quassnoi y @Guffa ya han arrojado algo de luz sobre esto.

En particular, nunca use char o char(n) (alias para character / character(n) ), a menos que sepa lo que está haciendo. Este tipo de relleno en blanco solo está ahí para compatibilidad con códigos y estándares antiguos. Tiene muy poco sentido hoy en día, desperdicia memoria y es probable que cause problemas:

• Comparar varchar con char

Para imponer una longitud máxima en una columna, aún use text (o varchar sin especificador de longitud, que es básicamente el mismo) y no varchar(n) (alias para character varying character varying(n) / character varying(n) ). Una restricción CHECK es mucho más conveniente para cambiar más tarde (sin reescritura de tabla), incluso más cuando las vistas, funciones, restricciones de FK, etc. dependen del tipo de columna.

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

Una restricción CHECK también puede hacer algo más que imponer un máximo, prácticamente cualquier cosa. Lee mas:

• Cambiar las columnas de PostgreSQL utilizadas en las vistas

Finalmente, también hay "char" (con comillas dobles): un tipo de datos de 1 byte para una sola letra ASCII utilizada como tipo de enumeración interna barata.

Raramente uso nada más que text para datos de personajes en Postgres.