Sucede que el producto que estamos desarrollando funciona con múltiples bases de datos relacionales. Ahora estos son MS SQL, Postgres y Oracle. Hubo lanzamientos de muchas cosas desde MySQL hasta los fallecidos, probablemente Firebird y el exótico Sybase con DB2, pero esa no es la historia.
Si con MS SQL y Postgres es cada vez menos comprensible y familiar, entonces con Oracle cada vez nos espera algunas sorpresas. Un lector astuto notará inmediatamente que "nuestras manos están torcidas" y "simplemente no sabemos cómo cocinarlo", pero si, querido lector, quiere saber en qué se varchar2
diferencia varchar (o mejor dicho ) en el Oráculo de Dios de sus hermanos, entonces por favor, debajo de cat.
Como todos los sistemas modernos, almacenamos datos en formato Unicode (actualmente UTF-8). ¿Por qué podría ser esto importante para las bases de datos relacionales?
Bueno, por ejemplo, si tiene una combinación de tipos de datos Unicode y no Unicode en su base de datos, algunos controladores no pueden hacer esto. Por ejemplo, JTDS: el controlador JDBC para el servidor MS SQL puede funcionar en modo Unicode o en Ansi. En consecuencia, si decide "guardar" y crear una columna no Unicode (varchar / char), obtendrá una conversión unicode-> ansi en el nivel de inserción de datos en la tabla y, muy probablemente, logre el efecto contrario (al menos ralentización en la inserción de datos, de lo contrario y en la búsqueda).
Entonces la historia. Nuestro servidor de aplicaciones verifica la longitud máxima permitida de los campos antes de insertarlos (aquí es necesario estipular que la verificación no se realiza de acuerdo con los datos de la base de datos, sino de acuerdo con nuestros metadatos internos), pero a pesar de esto, a veces bajo Oracle "capturamos" un error comoORA-12899: value too large for column.
? , , Oracle.
. , varchar2
:)
, ,
alter table address modify street varchar2(150);
150 - ( -)? - :) .
alter table address modify street varchar2(150 char);
.. char
-byte
. ( ) - .
, UTF-8, , 4 ( 1 ANSI, 2 4 ).
Unicode !? , , , " ". .. , : legacy, , Unicode' " ", , backup 86 imp - .
? tool, , create table
char
:)
:
, , , .
SELECT value FROM NLSDATABASEPARAMETERS WHERE parameter='NLSLENGTHSEMANTICS';
, , " ":
SELECT TABLE_NAME, COLUMN_NAME, DATA_LENGTH, CHAR_USED
FROM USER_TAB_COLUMNS
WHERE DATA_TYPE = 'VARCHAR2' AND CHAR_USED = 'B'
ORDER BY TABLE_NAME, COLUMN_NAME
P.S. , , (, 100% ansi ), Unciode … ...
P.P.S. Regexp " " varchar2\(\s*\d+\s*\)
P.P.P.S. StackOverflow
PPPPS Y esto es lo que Oracle piensa acerca de cambiar el valor del parámetro NLSLENGTHSEMANTICS
a algo más razonable "Oracle recomienda enfáticamente que NO establezca el parámetro NLS LENGTH SEMANTICS en CHAR en la instancia o en el archivo de parámetros del servidor. Esto puede causar que muchos scripts de instalación existentes crea columnas inesperadamente con semántica de longitud de caracteres, lo que da como resultado errores en tiempo de ejecución, incluidos desbordamientos de búfer ". https://docs.oracle.com/cd/E24693 01 / server.11203 / e24448 / initparams149.htm