¿El tipo de datos CHAR en SQL está obsoleto? ¿Cuando lo usas?

Question

El título prácticamente enmarca la pregunta. No he usado CHAR en años. En este momento, estoy realizando una ingeniería inversa de una base de datos que tiene CHAR por todas partes, para claves primarias, códigos, etc. ¿Qué tal una columna CHAR (30)?

Edit: Así que la opinión general parece ser que CHAR está perfectamente bien para ciertas cosas. Sin embargo, creo que puede diseñar un esquema de base de datos que no necesite "estas cosas determinadas", por lo que no requiere cadenas de longitud fija. Con los tipos bit, uniqueidentifier, varchar y text, parece que en un esquema bien normalizado se obtiene una cierta elegancia que no se obtiene cuando se utilizan valores de cadena codificados. Pensar en longitudes fijas, sin intención de ofender, parece ser una reliquia de los días del mainframe (aprendí RPG II una vez). Creo que es obsoleto, y no escuché un argumento convincente de usted que afirme lo contrario.

Answer 1

Cuando la naturaleza de los datos determina la longitud del campo, uso CHAR. De lo contrario, VARCHAR.

Answer 2

Los CAR son aún más rápidos de procesar que VARCHAR en el DBMS que conozco bien. Su tamaño fijo permite optimizaciones que no son posibles con VARCHAR. Además, los requisitos de almacenamiento son ligeramente menores para CHARS, ya que no se debe almacenar ninguna longitud, suponiendo que la mayoría de las filas llenen completa o casi completamente la columna CHAR.

Esto tiene un impacto menor (en términos de porcentaje) con un CHAR (30) que un CHAR (4).

En cuanto al uso, que tienden a utilizar CHAR cuando:

• los campos por lo general siempre estar cerca de o en su longitud máxima (códigos de valores, ID de empleado, etc.); o
• las longitudes son cortas (menos de 10).

En cualquier otro lado, utilizo VARCHARs.

Answer 3

Uso char (n) para códigos, varchar (m) para descripciones. Char (n) parece dar como resultado un mejor rendimiento porque los datos no necesitan moverse cuando cambia el tamaño del contenido.

Answer 4

Uso CHAR cuando la longitud del valor es fija. Por ejemplo, estamos generando un código o algo basado en algún algoritmo que devuelve el código con la longitud fija específica, digamos 13.

De lo contrario, encontré VARCHAR mejor. Una razón más para usar VARCHAR es que cuando recupera el valor en su aplicación, no necesita recortar ese valor. En el caso de CHAR obtendrás la longitud completa de la columna si el valor la completa o no. Se llenaría de espacios y terminaría recortando cada valor, y olvidando eso llevaría a errores.

Answer 5

El carbón no es obsoleto, solo debe usarse si la longitud del campo nunca debe variar. En la base de datos promedio, esto sería muy pocos campos en su mayoría algún tipo de campo de código como abreviaturas de estado que son un carácter estándar de 2 caracteres si utiliza los códigos postales. Usar Char en donde la longitud archivada es varaible significa que habrá una gran cantidad de recortes y eso es un trabajo extra e innecesario y la base de datos debe ser refactorizada.

Answer 6

Para PostgreSQL, la documentación indica que char() no tiene ninguna ventaja en el espacio de almacenamiento sobre varchar(); la única diferencia es que está acolchada en blanco a la longitud especificada.

Habiendo dicho eso, todavía uso char(1) o char(3) para códigos de un carácter o tres caracteres. Creo que la claridad debida al tipo que especifica qué debe contener la columna proporciona valor, incluso si no hay ventajas de almacenamiento o rendimiento. Y sí, normalmente uso restricciones de verificación o restricciones de clave externa también. Además de esos casos, generalmente solo me quedo con text en lugar de usar varchar(). De nuevo, esto se basa en la implementación de la base de datos, que cambia automáticamente de almacenamiento en línea a fuera de línea si el valor es lo suficientemente grande, lo que algunas otras implementaciones de bases de datos no hacen.