Meine persönliche Präferenz ist es, die Bind-Variablen zu Zeichenketten (VARCHAR2) zu machen und Oracle die Konvertierung von Zeichen in sein eigenes internes Speicherformat zu überlassen. Es ist einfach genug (in C), Datenwerte in einem akzeptablen Format als nullterminierte Zeichenfolgen darzustellen.
Anstatt also SQL wie folgt zu schreiben:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
Ich schreibe das SQL wie folgt:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
und geben Sie Zeichenfolgen als Bind-Variablen an.
Dieser Ansatz hat einige Vorteile.
Eine davon umgeht die Probleme und Fehler, die beim Binden anderer Datentypen auftreten.
Ein weiterer Vorteil besteht darin, dass Bind-Werte in einem Oracle Event 10046-Trace leichter zu entschlüsseln sind.
Außerdem erwartet ein EXPLAIN PLAN (glaube ich), dass alle Bind-Variablen VARCHAR2 sind, was bedeutet, dass sich die zu erklärende Anweisung geringfügig von der tatsächlich ausgeführten Anweisung unterscheidet (aufgrund der impliziten Datenkonvertierungen, wenn die Datentypen der Bind-Argumente in der tatsächlichen -Anweisung sind nicht VARCHAR2.)
Und (weniger wichtig) wenn ich die Anweisung in TOAD teste, ist es einfacher, einfach Strings in die Eingabefelder eingeben zu können und sich nicht mit dem Ändern des Datentyps in einem Dropdown-Listenfeld herumschlagen zu müssen.
Ich lasse auch die eingebauten Funktionen TO_NUMBER und TO_DATE die Daten validieren. (Zumindest in früheren Versionen von Oracle bin ich auf Probleme mit der direkten Bindung eines DATE-Werts gestoßen, und es hat die Gültigkeitsprüfung (zumindest teilweise) umgangen und erlaubt, dass ungültige Datumswerte in der Datenbank gespeichert werden.
Dies ist nur eine persönliche Präferenz, basierend auf früheren Erfahrungen. Ich verwende denselben Ansatz mit Perl DBD.
Ich frage mich, was Tom Kyte (asktom.oracle.com) zu diesem Thema zu sagen hat?
