Tipo de datos de Oracle: ¿Debo usar VARCHAR2 o CHAR

Question

¿Debo usar VARCHAR2 o CHAR como un tipo de datos en Oracle?

Se me ha sugerido que use CHAR para estas nuevas tablas que necesito, pero me preocupan las nuevas tablas que se usarán para poblar las tablas existentes que usan un tipo de datos VARCHAR2. Me preocupan los espacios adicionales que se colocan en los campos de VARCHAR2 y los problemas de comparación. Sé que hay formas de compararlos usando recortarlos o convertirlos, pero me temo que esto hará que mi código se vuelva desordenado y problemático.

¿Cuáles son sus opiniones?

Answer 1

Me preocupan los espacios adicionales que se colocan en los campos VARCHAR2 y los problemas de comparación. Sé que hay formas de compararlos usando recortarlos o convertirlos, pero me temo que esto hará que mi código se vuelva desordenado y problemático.

En realidad es todo lo contrario. El uso de CHAR obligará a las cuerdas a ser de una longitud fija rellenándolas con espacios si son demasiado cortas. Por lo tanto, al comparar CHARs con cadenas regulares en cualquier aplicación que esté utilizando los datos, esa aplicación debería agregar un ajuste cada vez. En otras palabras, VARCHAR2 es la elección que conduce naturalmente a un código más limpio.

En general, debe siempre usar VARCHAR2, a menos que tenga un motivo muy específico por el que desea una columna CHAR.

Si usted está preocupado acerca de las cadenas que tienen espacios adicionales en el frente o al final, entonces hay algunas opciones que vienen a la mente:

• Asegúrese de que cualquier proceso que está haciendo los insertos hace un ajuste en ellas antes de insertar.
• Agregue una restricción de verificación en la columna que asegure que string = trim (cadena).
• Agregue un desencadenante de nivel de fila antes de insertar que recorte las cadenas a medida que se insertan.
• Asegúrese de que lo haga un ajuste en las cuerdas cada vez que se consulta la tabla

Answer 2

Yo sugeriría que se apegue a VARCHAR2.

Debe usar CHAR cuando los datos tienen una longitud fija conocida.

Answer 3

CHAR tiene una semántica de comparación interesante. Si solo usa VARCHAR2, entonces no necesita aprender la semántica CHAR. Honestamente, creo que si tuviera un campo con una lenth fija conocida, aún así lo definiría como VARCHAR2 y usaría una restricción de verificación para aplicar su longitud fija, en lugar de aprender la semántica de comparación CHAR.

Algunos argumentarán que los CHAR son más eficientes para los datos de longitud fija porque la longitud no necesita almacenarse, pero es untrue on Oracle.

Answer 4

Leer:

• CHAR versus VARCHAR2 Semantics (documentation)
• Should I use char or varchar2 (AskTom)

Presupuesto de artículo AskTom:

El hecho de que un CHAR/NCHAR no sea más que un VARCHAR2/NVARCHAR2 disfrazado me hace pensar que hay realmente solo dos tipos de cadenas de caracteres para considerar, es decir, VARCHAR2 y NVARCHAR2. Nunca he encontrado un uso para el tipo CHAR en ninguna aplicación. Como un tipo CHAR siempre en blanco rellena la cadena resultante con un ancho fijo, descubrimos rápidamente que consume almacenamiento máximo tanto en el segmento de la tabla como en cualquier segmento de índice. Eso sería suficientemente malo, pero hay otra razón importante para evitar CHAR/NCHAR tipos: crean confusión en las aplicaciones que necesitan recuperar esta información (muchos no pueden "encontrar" sus datos después de almacenar ). La razón de esto se relaciona con las reglas de la cadena de caracteres comparación y la rigurosidad con la que se realizan.

Answer 5

Elija VARCHAR2(size) sobre CHAR(size), ya que esto es más espacio y tiempo eficiente:

Sorprendentemente o no, CHAR(size) permite la asignación de cadenas con una longitud más corta que lensize. En este caso, ORACLE agrega size-len espacios a la cadena para los tipos de datos CHAR y VARCHAR y almacena size caracteres. El tipo de datos VARCHAR2 viene sin relleno, solo se almacenan len caracteres.

CREATE TABLE Demo(col1 CHAR(4), col2 VARCHAR2(4)); 
INSERT INTO Demo (col1, col2) VALUES ('c', 'v'); 

Como resultado,

col1='c ' (acolchado con 3 espacios finales, ya que el size de col1 es 4 y la longitud de 'c' sólo es 1). col1='c' evalúa FALSO, sólo se TRIM(col1)='c' evalúa como TRUE,

mientras que

col2='v' se evalúe como verdadera sin TRIM(), por lo que la comparación sea más eficiente.

Además, las comparaciones entre dos valores VARCHAR2 fallan rápidamente si sus longitudes difieren (independientemente de su size). En este caso, no se requieren comparaciones entre caracteres. Con CHAR y el mismo size, la verificación de longitud siempre falla debido al relleno. Por lo tanto, se debe comparar cada personaje hasta que se haya alcanzado el primer carácter no coincidente o el final de la cadena, lo que ocurra primero.

Dado que tanto CHAR(size) y VARCHAR2(size) no impiden asignaciones de valores más cortos que size, definir una restricción de longitud si es necesario para asegurar que sólo se valora con una longitud predefinida (que debe ser igual size) puede ser asignada.