La mia preferenza personale è quella di rendere le stringhe di caratteri delle variabili di collegamento (VARCHAR2) e lasciare che Oracle esegua la conversione dal carattere al proprio formato di archiviazione interna. È abbastanza facile (in C) ottenere valori di dati rappresentati come stringhe con terminazione null, in un formato accettabile.
Quindi, invece di scrivere SQL in questo modo:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Scrivo l'SQL in questo modo:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
e fornisci stringhe di caratteri come variabili di collegamento.
Ci sono un paio di vantaggi in questo approccio.
Uno è che risolve i problemi e i bug che si incontrano con l'associazione di altri tipi di dati.
Un altro vantaggio è che i valori di associazione sono più facili da decifrare su una traccia dell'evento Oracle 10046.
Inoltre, un EXPLAIN PLAN (credo) si aspetta che tutte le variabili di collegamento siano VARCHAR2, quindi ciò significa che l'istruzione spiegata è leggermente diversa dall'istruzione effettiva in esecuzione (a causa delle conversioni di dati implicite quando i tipi di dati degli argomenti di collegamento nell'attuale non sono VARCHAR2.)
E (meno importante) quando sto testando l'istruzione in TOAD, è più semplice essere in grado di digitare stringhe nelle caselle di input e non dover cambiare il tipo di dati in una casella di riepilogo a discesa.
Ho anche lasciato che le funzioni TO_NUMBER e TO_DATE convalidino i dati. (Almeno nelle versioni precedenti di Oracle, ho riscontrato problemi con l'associazione diretta di un valore DATE e ha ignorato (almeno parte) il controllo della validità e consentito l'archiviazione nel database di valori di data non validi.
Questa è solo una preferenza personale, basata sull'esperienza passata. Uso questo stesso approccio con Perl DBD.
Mi chiedo cosa abbia da dire Tom Kyte (asktom.oracle.com) su questo argomento?
