tipo - varchar2 oracle max size

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

Question

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

Se me sugirió usar 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 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.

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, siempre debe usar VARCHAR2, a menos que tenga una razón muy específica por la que desea una columna CHAR.

Si le preocupan las cadenas que tienen espacios adicionales en el frente o al final, entonces hay algunas opciones que le vienen a la mente:

• Asegúrese de que cualquier proceso que esté haciendo las inserciones haga un recorte sobre ellas antes de insertarlas.
• Agregue una restricción de verificación en la columna que asegure que string = trim (cadena).
• Agregue un disparador de nivel de fila antes de insertar que recorte las cadenas a medida que se insertan.
• Asegúrate de hacer un recorte en las cuerdas siempre que consultes la tabla

Answer 2

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 datos de longitud fija porque no es necesario almacenar la longitud, pero eso no es cierto en Oracle .

Answer 3

Sugeriría que te apegues a VARCHAR2.

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

Answer 4

Leer:

• CHAR versus Semántica VARCHAR2 (documentación)
• ¿Debo usar char o varchar2 (AskTom)

Cita del artículo de AskTom:

El hecho de que un CHAR / NCHAR no sea más que un VARCHAR2 / NVARCHAR2 disfrazado me hace pensar que realmente solo hay dos tipos de cadenas de caracteres para considerar, como 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 el almacenamiento máximo tanto en el segmento de la tabla como en cualquier segmento del índice. Eso sería suficientemente malo, pero hay otra razón importante para evitar los tipos CHAR / NCHAR: crean confusión en las aplicaciones que necesitan recuperar esta información (muchos no pueden "encontrar" sus datos después de almacenarlos). La razón de esto se relaciona con las reglas de comparación de cadenas de caracteres y el rigor con el que se realizan.

Answer 5

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

Sorprendentemente o no, CHAR(size) permite la asignación de cadenas con un largo inferior al size . En este caso, ORACLE agrega espacios de size-len a la cadena para los tipos de datos CHAR y VARCHAR y almacena caracteres de size . El tipo de datos VARCHAR2 viene sin relleno, solo se almacenan los caracteres len .

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

Como resultado,

col1=''c '' (rellenado con 3 espacios finales, ya que el size de col1 es 4 y la longitud de ''c'' es solo 1). col1=''c'' evalúa FALSE, solo TRIM(col1)=''c'' evalúa TRUE,

mientras

col2=''v'' evalúa TRUE sin TRIM() , lo que hace 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.

Como CHAR(size) y VARCHAR2(size) no impiden asignaciones de valores más cortos que el size , defina una restricción de longitud si necesita asegurarse de que solo se pueden asignar valores con una longitud predefinida (que debe ser igual a size ).