¿Por qué Oracle varchar2 tiene un tamaño obligatorio como parámetro de definición?

Question

Quiero saber por qué Oracle necesita el parámetro de tamaño en la definición de VARCHAR2.

Creo que es por limitaciones. ¿Sería una mejor opción que Oracle tome este parámetro como un tipo de datos opcional como NUMBER?

A menudo tengo problemas para cambiar el tamaño de tablas antiguas a tamaños más grandes, porque a veces un valor es más grande que la definición de tamaño de la columna VARCHAR2.

Es lo mismo definir un tipo de VARCHAR2(10) o VARCHAR2(1000).

Supongo que es una restricción innecesaria. Si no, ¿sabe de un caso real cuando esta restricción dio como resultado algo útil? ¿Y por qué no hay tal declaración en el tipo NUMBER?

Answer 1

Es lo mismo definir un tipo de varchar2 (10) o varchar2 (1000).

No, no es lo mismo en absoluto.

1. La longitud de la columna es un metadato útil para desarrolladores que crean pantallas.
2. De manera similar, las herramientas de consulta automática como TOAD y SQL Developer usan la longitud de la columna cuando muestran los resultados.
3. La base de datos usa la longitud de una variable al asignar memoria para colecciones PL/SQL. A medida que esa memoria sale de la superposición de PGA, la declaración de variables puede provocar errores en los programas porque el servidor se ha quedado sin memoria.
4. Existen problemas similares con la declaración de variables individuales en programas PL/SQL, es solo que las colecciones tienden a multiplicar el problema.
5. Las columnas extragrandes crean problemas para los índices compuestos. A continuación se presenta en una base de datos con 8K bloques

....

SQL> create table t23 (col1 varchar2(4000), col2 varchar2(4000)) 
    2/

Table created. 

SQL> create index t23_i on t23(col1,col2) 
    2/
create index t23_i on t23(col1,col2) 
         * 
ERROR at line 1: 
ORA-01450: maximum key length (6398) exceeded 


SQL> 

Pero por encima de todo, columnas tamaños son una forma de comprobación de errores. Si se supone que la columna tiene diez caracteres de longitud y algún proceso autónomo está tratando de cargar mil caracteres, entonces algo está mal. El proceso debería fallar, por lo que podemos investigar por qué estamos cargando datos duff. La alternativa es una base de datos llena de basura, y si eso es lo que queríamos deberíamos haberle dado a todos Excel y haberlo hecho.

Es cierto que cambiar el tamaño de la columna cuando resulta que hemos subestimado puede ser fastidioso. Pero no ocurre muy a menudo, y podemos mitigar mucho el dolor utilizando declaraciones% TYPE y SUBTYPE en nuestro PL/SQL en lugar de longitudes variables de codificación dura.

---

"¿por qué hay tal declaración en el tipo de número"

números son diferentes. Para empezar, el tamaño máximo de un número es mucho menor que el texto equivalente (38 dígitos de precisión garantizada).

Pero la diferencia clave es que Oracle almacena los valores numéricos in scientific notation, por lo que no existe una relación directa entre el tamaño aritmético del número y el espacio de almacenamiento que consume.

SQL> select vsize(123456789) n1 
    2   , vsize(999999999999999999999999999999) n2 
    3   , vsize(0.000000000000000000001) n3 
    4   , vsize(1000000000000000000000000) n4 
    5 from dual 
    6/

     N1   N2   N3   N4 
---------- ---------- ---------- ---------- 
     12   16   2   2 

SQL> 

Sin embargo, sigue siendo buena práctica especificar la escala y precisión siempre que sea posible, especialmente cuando se trata de números enteros, por ejemplo, o dinero.

Answer 2

A pesar de que no asigna un número fijo de bytes en el disco como un campo Char serían, todavía hay razones dignas para dimensionamiento:

• de asignación de memoria en el lector de datos (basado en el tamaño máximo de fila)
• Indexación de una gran columna trae tamaños de bloque en juego
• Etc ...

estoy seguro de que hay más razones que alguien pueda imaginar, pero esos son los que he visto en un pasado proj ect donde alguien eligió varchar2(4000) todo.

Answer 3

¿Por qué no tener cada columna en cada tabla de base de datos como un CLOB? De esa manera usted no tiene que preocuparse acerca de las longitudes máximas ...

Pero, en serio:

limitaciones tipo de datos de la longitud están allí por la misma razón que cualquier restricción: reducen la cantidad de comprobación de errores que necesita para rociar todo el código de su aplicación, asegurándose de que los datos almacenados con éxito en la tabla cumplan con las restricciones que ha definido.

Answer 4

Desde el punto de vista de la extracción de información, es muy útil saber qué tan grande es el campo. Por ejemplo, si tiene que imprimir la dirección en un sobre o mostrarla en una pantalla, desea saber qué tan grande debe ser el campo.

O compre sobres MUY grandes.

Answer 5

Creo que es importante recordar el contexto histórico en el que se desarrollaron las bases de datos relacionales. En el momento en que se desarrollaron (finales de los 70 y principios de los 80) las computadoras comúnmente disponibles eran mucho más pequeñas (en términos de memoria y espacio en disco) y menos poderosas (en términos de CPU) que las que tenemos ahora, y la administración de estos recursos era necesariamente una una preocupación apremiante COBOL era el lenguaje común de la informática empresarial (y todavía se usa ampliamente), y los lenguajes orientados a objetos como Smalltalk y C++ eran desconocidos, para todos los propósitos prácticos. En ese momento, se esperaba que los programas declararan con precisión la cantidad de almacenamiento que necesitarían para cada elemento de datos, p. 10 bytes para una cadena, 2 bytes para un entero corto, 4 bytes para una flotación, etc., y así este estilo de declaración fue utilizado por las bases de datos relacionales recién desarrolladas. Más al punto, se hizo la asunción que cada elemento de datos declararía (implícita o explícitamente) la cantidad de almacenamiento que requería, y esto se codificó en los motores relacionales en un nivel muy fundamental.

Ahora, con el tiempo, este requisito se ha relajado un poco, al menos en lo que se refiere al almacenamiento de los datos en el disco. Creo que en Oracle, el tipo de datos NUMBER asignará espacio de forma flexible, de modo que solo se utilizará la cantidad mínima de espacio necesaria para almacenar su valor, y que las columnas VARCHAR2 solo usarán suficiente espacio en disco para almacenar los datos reales sin almacenar espacios en blanco al final aunque aún necesita declarar la cantidad máxima de almacenamiento requerida para un VARCHAR2.

Puede echar un vistazo al SYS.Paquete ESTÁNDAR para tener una idea de cómo declarar los subtipos VARCHAR2. Por ejemplo, si usted quiere su propio tipo 'cadena', que se puede utilizar sin virar en una especificación de longitud puede intentar:

SUBTYPE MY_STRING IS VARCHAR2(4000); 

Sin embargo, tenga cuidado con esto si usted va a indexar la columna en cuestión (como se señaló anteriormente por @APC).

Acepto que prefiero poder declarar un STRING (que, por cierto, se define en SYS.STANDARD como un subtipo de VARCHAR2) sin tener que declarar una longitud, pero así es como funciona Oracle. y como no voy a comenzar a escribir mi propia base de datos relacional (tengo mis propios molinos de viento en los que basarme, gracias :-) Voy a estar de acuerdo con el status quo.

Espero que esto ayude.

Answer 6

Existe un posible impacto en el rendimiento: en MySQL, temporary tables y MEMORY tables almacena una columna VARCHAR como una columna de longitud fija, acolchada a su longitud máxima.

Si diseña VARCHAR columnas mucho más grandes que el tamaño máximo que necesita, consumirá más memoria de la que necesita. Esto afecta a cache efficiency, sorting speed, etc.

Así que le das la longitud máxima que está debajo de tu cuerda. como si tu longitud máxima de personaje es 10, así que no le des a su longitud 100 o más.