Mi preferencia personal es hacer que las cadenas de caracteres de las variables de vinculación (VARCHAR2) y dejar que Oracle haga la conversión de caracteres a su propio formato de almacenamiento interno. Es bastante fácil (en C) obtener valores de datos representados como cadenas terminadas en nulo, en un formato aceptable.
Entonces, en lugar de escribir SQL así:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Escribo el SQL así:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
y suministre cadenas de caracteres como variables de vinculación.
Hay un par de ventajas en este enfoque.
Una es que soluciona los problemas y errores que se encuentran al vincular otros tipos de datos.
Otra ventaja es que los valores de vinculación son más fáciles de descifrar en un seguimiento del evento 10046 de Oracle.
Además, EXPLAIN PLAN (creo) espera que todas las variables de vinculación sean VARCHAR2, lo que significa que la declaración que se explica es ligeramente diferente de la declaración real que se ejecuta (debido a las conversiones de datos implícitas cuando los tipos de datos de los argumentos de vinculación en el real declaración no son VARCHAR2.)
Y (menos importante) cuando estoy probando la declaración en TOAD, es más fácil poder escribir cadenas en los cuadros de entrada y no tener que cambiar el tipo de datos en un cuadro de lista desplegable.
También dejo que las funciones integradas TO_NUMBER y TO_DATE validen los datos. (Al menos en versiones anteriores de Oracle, encontré problemas al vincular un valor de FECHA directamente, y omitió (al menos parte de) la verificación de validez y permitió que los valores de fecha no válidos se almacenaran en la base de datos.
Esto es solo una preferencia personal, basada en experiencias pasadas. Yo uso este mismo enfoque con Perl DBD.
Me pregunto qué tiene que decir Tom Kyte (asktom.oracle.com) sobre este tema.
