Valores ‘DEFAULT’ para escala y precisión de ‘DATATYPES’ en definiciones de tablas.

Últimamente estoy trabajando con un sistema de fuente de datos Oracle en el cual sus diseñadores (por llamarlos así) no han puesto mucho mimo, que digamos.

Para incorporar datos de fuentes de sistemas externos a Teradata (p. ej.: sistemas Oracle) se suele pedir un modelo de datos del sistema fuente en cuestión (preferiblemente en PowerDesigner) para diseñar a su vez el modelo receptor en el ‘DataWarehouse’. Y es ahí donde ves lo poco que le preocupa a los equipos de desarrollo -incluidos analistas y diseñadores(¡¡!!)- un buen diseño de sus sistemas.

Pues bien, es frecuente encontrar en esos diseños que las escalas de los tipos de datos brillan por su ausencia o están fijadas a valores ‘por defecto’ de las herramientas de diseño que utilizan (si es que realmente las utilizan. O mejor dicho: si es que realmente diseñan). Así vemos que en un diseño dado, curiosamente todas las columnas de texto son VARCHAR2(255) o VARCHAR2(32) o cualquiera que sea el valor elegido…

Pero eso no es lo peor: a veces nos llegan columnas con el tipo CHAR (así, sin escala) o NUMBER (sin escala ni precisión) y esto puede llegar a ser un problema, ya que aunque ciertos valores son comunes, hay otros que difieren, y mucho. Si uno no está avisado puede llegar a ser un verdadero problema.

En general, los diferentes RDBMS se ponen de acuerdo en que cuando se dice ‘CHAR’ en realidad se está diciendo ‘CHAR(1)’, y que si se dice ‘TIMESTAMP’ en realidad se está diciendo ‘TIMESTAMP(6)’. Pero, ¿qué pasa con los valores numéricos? pues que las cosas se empiezan a torcer…

En Oracle un a columna definida NUMBER (sin escala) puede almacenar numeros como ‘double precission’ asegurando una precisión decimal de 38 dígitos:

CARLOS@XE.localhost> CREATE TABLE PRUEBATIPOS
  2       ( COL1 CHAR NOT NULL,
  3         COL3 NUMBER NOT NULL,
  4         COL6 TIMESTAMP NOT NULL
  5       )
  6  ;

Tabla creada.

CARLOS@XE.localhost> set linesize 80
CARLOS@XE.localhost> desc PRUEBATIPOS;
 Nombre                                    ¿Nulo?   Tipo
 ----------------------------------------- -------- ------------
 COL1                                      NOT NULL CHAR(1)
 COL3                                      NOT NULL NUMBER
 COL6                                      NOT NULL TIMESTAMP(6)

CARLOS@XE.localhost> INSERT INTO PRUEBATIPOS
  2  VALUES ('A',12345678901234567890123456789012345678,SYSDATE);

1 fila creada.

CARLOS@XE.localhost> SELECT TO_CHAR(COL3,'9999999999999999999999999999999999999999')
  2  FROM PRUEBATIPOS;

TO_CHAR(COL3,'999999999999999999999999999
-----------------------------------------
   12345678901234567890123456789012345678

Pero el caso es que en Teradata cuando se define una columna DECIMAL (o su sinónimo NUMERIC), sin escala ni precisión, en realidad se está definiendo la columna como DECIMAL(5,0):

 BTEQ -- Enter your DBC/SQL request or BTEQ command:
CREATE MULTISET TABLE MY_DB.PRUEBATIPOS ,
     NO FALLBACK,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT
     ( COL1 CHAR NOT NULL,
       COL2 DECIMAL NOT NULL,
       COL3 NUMERIC NOT NULL,
       COL4 BYTE NOT NULL,
       COL5 TIME NOT NULL,
       COL6 TIMESTAMP NOT NULL
     )
PRIMARY INDEX ( COL1 )
;

 *** Table has been created.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your DBC/SQL request or BTEQ command:
SHOW TABLE MY_DB.PRUEBATIPOS;

 *** Text of DDL statement returned.
 *** Total elapsed time was 1 second.

------------------------------------------------------------------
CREATE MULTISET TABLE MY_DB.PRUEBATIPOS ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT
     (
      COL1 CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
      COL2 DECIMAL(5,0) NOT NULL,
      COL3 DECIMAL(5,0) NOT NULL,
      COL4 BYTE(1) NOT NULL,
      COL5 TIME(6) NOT NULL,
      COL6 TIMESTAMP(6) NOT NULL)
PRIMARY INDEX ( COL1 );

Me ahorro comentar los quebraderos de cabeza que se pueden llegar a producir cuando se incorporen las columnas definidas NUMBER Oracle a las columnas definidas DECIMAL en Teradata.

Ni que decir tiene que un modelo bien hecho debería tener bien definidos (y razonados) los valores de escala y precisión de todas y cada una de las columnas de todas y cada una de las tablas.

Así que, ojito a los diseñadores descuidados y sus consecuencias a la hora de importar modelos.

(En el ejemplo se han incluido columnas de diferentes tipos para mostrar los valores de escala por defecto estándar indicados al principio de la entrada)

Saludos.

Carlos.

3 respuestas a Valores ‘DEFAULT’ para escala y precisión de ‘DATATYPES’ en definiciones de tablas.

  1. Óscar de la Torre dice:

    Precisamente hace poco me he encontrado con problemas relacionados con la omisión de precisión y escala.

    Siendo en Teradata NUMBER(5,0) el papelón qu tienes es tremendo:


    ops$oskar@test11g$ create table t (x number);

    Table created.

    ops$oskar@test11g$ insert into t values (.111111111122222222223333333333444444444445555555555);

    1 row created.

    ops$oskar@test11g$ col x for 999999999999.999999999999999999999999999999999999999999999999
    ops$oskar@test11g$ select * from t;

    X
    --------------------------------------------------------------
    .111111111122222222223333333333444444444400000000

    ops$oskar@test11g$ insert into t values (5555555555.1111111111222222222233333333334444444444);

    1 row created.

    ops$oskar@test11g$ select * from t;

    X
    --------------------------------------------------------------
    .111111111122222222223333333333444444444400000000
    5555555555.111111111122222222223333333333000000000000000000

    Todo esto sin mencionar cuando a alguien se le ocurre la brillante idea de guardar fechas como números y/o cadenas de texto.

  2. carlosal dice:

    Óscar:

    Siempre es un gusto verte por aquí.

    Supongo que tú especificas escala y precisión en todas las columnas numéricas😉

    Lo que me jode es que ese tipo de cosas siempre ocurren por desidia.

    BTW ¿Has probado la 11gR2? ¿Qué tal va? ¿Me la bajo ya😉 ?

    Saludos.

    Carlos.

    • Óscar de la Torre dice:

      Pues la verdad es que intento especificarlos si bien es verdad que todos somos falibles. Lo que no me asusta es corregir mis errores/omisiones.

      Coincido con la causa principal es la desidia. El problema es que parece que cuando le comentas a alguien un fallo en su diseño/planteamiento o manifiestas dudas, muchas veces se lo toman como algo personal. Desde luego, nada más lejos de mi intención. Bien es verdad que hay personas receptivas que se lo toman como un intercambio profesional de opiniones, pero lamentablemente son las menos.

      Perdón por la diatriba pero ando algo frustrado últimamente.

      De la 11gR2 he visto poco, más la parte de RAC que otra cosa. En ese aspecto es un mundo nuevo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: