Min personliga preferens är att göra bindningsvariablerna teckensträngar (VARCHAR2), och låta Oracle göra omvandlingen från tecken till sitt eget interna lagringsformat. Det är tillräckligt enkelt (i C) att få datavärden representerade som nollterminerade strängar, i ett acceptabelt format.
Så istället för att skriva SQL så här:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Jag skriver SQL så här:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
och ange teckensträngar som bindningsvariabler.
Det finns ett par fördelar med detta tillvägagångssätt.
Det ena är att det går runt de problem och buggar man stöter på när man binder andra datatyper.
En annan fördel är att bindningsvärden är lättare att dechiffrera på en Oracle-händelse 10046-spårning.
En EXPLAIN-PLAN (tror jag) förväntar sig också att alla bindningsvariabler är VARCHAR2, så det betyder att satsen som förklaras är något annorlunda än den faktiska satsen som körs (på grund av de implicita datakonverteringarna när bindningsargumentens datatyper i själva uttalandet är inte VARCHAR2.)
Och (mindre viktigt) när jag testar påståendet i TOAD är det lättare att bara kunna skriva in strängar i inmatningsrutorna och inte behöva krångla med att ändra datatypen i en listruta.
Jag låter också funktionerna TO_NUMBER och TO_DATE validera data. (Åtminstone i tidigare versioner av Oracle stötte jag på problem med att binda ett DATE-värde direkt, och det kringgick (åtminstone en del av) giltighetskontrollen och tillät att ogiltiga datumvärden lagrades i databasen.
Detta är bara en personlig preferens, baserat på tidigare erfarenheter. Jag använder samma tillvägagångssätt med Perl DBD.
Jag undrar vad Tom Kyte (asktom.oracle.com) har att säga om detta ämne?