No, no es lo mismo en absoluto.
- La longitud de la columna es un metadato útil para los desarrolladores que crean pantallas.
- De manera similar, las herramientas de consulta automática como TOAD y SQL Developer usan la longitud de la columna cuando generan resultados.
- La base de datos usa la longitud de una variable cuando asigna memoria para colecciones PL/SQL. A medida que esa memoria sale del PGA, el sobredimensionamiento de la declaración de variables puede hacer que los programas fallen porque el servidor se ha quedado sin memoria.
- Hay problemas similares con la declaración de variables individuales en los programas PL/SQL, solo que las colecciones tienden a multiplicar el problema.
- Las columnas de gran tamaño crean problemas para los índices compuestos. Lo siguiente está en una base de datos con bloques de 8K
....
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, los tamaños de las columnas son una forma de verificación de errores. Si se supone que la columna tiene diez caracteres y algún proceso autónomo intenta cargar mil caracteres, entonces algo anda mal. El proceso debería fallar, por lo que podemos investigar por qué estamos cargando datos falsos. 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 terminar con eso.
Es cierto que cambiar el tamaño de la columna cuando resulta que lo hemos subestimado puede resultar tedioso. Pero no sucede muy a menudo, y podemos mitigar gran parte del dolor usando declaraciones %TYPE y SUBTYPE en nuestro PL/SQL en lugar de codificar longitudes variables.
Los números son diferentes. Para empezar, el tamaño máximo de un número es mucho más pequeño que el equivalente en texto (38 dígitos de precisión garantizada).
Pero la diferencia clave es que Oracle almacena valores numéricos en notación científica 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(123456789012345678901) 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>
No obstante, sigue siendo una buena práctica especificar la escala y la precisión siempre que sea posible, especialmente cuando se trata de números enteros, por ejemplo, o dinero.
