Min personlige præference er at lave bindevariablernes tegnstrenge (VARCHAR2), og lade Oracle lave konverteringen fra tegn til dets eget interne lagerformat. Det er nemt nok (i C) at få dataværdier repræsenteret som null-terminerede strenge i et acceptabelt format.
Så i stedet for at skrive SQL sådan her:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Jeg skriver SQL'en sådan her:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
og angiv tegnstrenge som bindevariabler.
Der er et par fordele ved denne tilgang.
Den ene er, at den løser de problemer og fejl, man støder på, når man binder andre datatyper.
En anden fordel er, at bindeværdier er nemmere at dechifrere på en Oracle-hændelse 10046-sporing.
Også en EXPLAIN PLAN (tror jeg) forventer, at alle bindevariabler er VARCHAR2, så det betyder, at sætningen, der forklares, er lidt anderledes end den faktiske sætning, der udføres (på grund af de implicitte datakonverteringer, når datatyperne af bindeargumenterne i den faktiske sætningen er ikke VARCHAR2.)
Og (mindre vigtigt), når jeg tester sætningen i TOAD, er det nemmere bare at være i stand til at skrive strenge i input-felterne, og ikke skulle rode med at ændre datatypen i en dropdown-liste.
Jeg lader også funktionerne TO_NUMBER og TO_DATE validere dataene. (I det mindste i tidligere versioner af Oracle stødte jeg på problemer med at binde en DATE-værdi direkte, og den omgik (i det mindste noget af) gyldighedskontrollen og tillod, at ugyldige datoværdier blev gemt i databasen.
Dette er kun en personlig præference, baseret på tidligere erfaringer. Jeg bruger den samme tilgang med Perl DBD.
Jeg spekulerer på, hvad Tom Kyte (asktom.oracle.com) har at sige om dette emne?