Minha preferência pessoal é fazer as strings de caracteres das variáveis de ligação (VARCHAR2) e deixar o Oracle fazer a conversão do caractere para seu próprio formato de armazenamento interno. É bastante fácil (em C) obter valores de dados representados como strings terminadas em nulo, em um formato aceitável.
Então, em vez de escrever SQL assim:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Eu escrevo o SQL assim:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
e forneça cadeias de caracteres como variáveis de ligação.
Existem algumas vantagens nessa abordagem.
Uma é que contorna os problemas e bugs encontrados ao vincular outros tipos de dados.
Outra vantagem é que os valores de ligação são mais fáceis de decifrar em um rastreamento de evento 10046 do Oracle.
Além disso, um EXPLAIN PLAN (eu acredito) espera que todas as variáveis de ligação sejam VARCHAR2, então isso significa que a instrução que está sendo explicada é um pouco diferente da instrução real que está sendo executada (devido às conversões de dados implícitas quando os tipos de dados dos argumentos de ligação no instrução não são VARCHAR2.)
E (menos importante) quando estou testando a instrução no TOAD, é mais fácil apenas poder digitar strings nas caixas de entrada e não precisar alterar o tipo de dados em uma caixa de listagem suspensa.
Também deixo as funções buitin TO_NUMBER e TO_DATE validarem os dados. (Pelo menos em versões anteriores do Oracle, encontrei problemas ao vincular um valor DATE diretamente e ele ignorou (pelo menos parte) a verificação de validade e permitiu que valores de data inválidos fossem armazenados no banco de dados.
Esta é apenas uma preferência pessoal, baseada em experiências anteriores. Eu uso essa mesma abordagem com Perl DBD.
Gostaria de saber o que Tom Kyte (asktom.oracle.com) tem a dizer sobre esse assunto?
