Ma préférence personnelle est de créer des chaînes de caractères pour les variables de liaison (VARCHAR2) et de laisser Oracle effectuer la conversion du caractère vers son propre format de stockage interne. Il est assez facile (en C) d'obtenir des valeurs de données représentées sous forme de chaînes à terminaison nulle, dans un format acceptable.
Ainsi, au lieu d'écrire du SQL comme ceci :
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
J'écris le SQL comme ceci :
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
et fournissez des chaînes de caractères comme variables de liaison.
Il y a quelques avantages à cette approche.
L'une est qu'elle contourne les problèmes et bogues que l'on rencontre avec la liaison d'autres types de données.
Un autre avantage est que les valeurs de liaison sont plus faciles à déchiffrer sur une trace d'événement Oracle 10046.
De plus, un EXPLAIN PLAN (je crois) s'attend à ce que toutes les variables de liaison soient VARCHAR2, ce qui signifie que l'instruction expliquée est légèrement différente de l'instruction réelle en cours d'exécution (en raison des conversions de données implicites lorsque les types de données des arguments de liaison dans le réel l'instruction ne sont pas VARCHAR2.)
Et (moins important) lorsque je teste l'instruction dans TOAD, il est plus simple de pouvoir saisir des chaînes dans les zones de saisie et de ne pas avoir à modifier le type de données dans une zone de liste déroulante.
Je laisse également les fonctions buitin TO_NUMBER et TO_DATE valider les données. (Dans les versions antérieures d'Oracle au moins, j'ai rencontré des problèmes avec la liaison directe d'une valeur DATE, et cela a contourné (au moins une partie) la vérification de validité et a permis de stocker des valeurs de date non valides dans la base de données.
Ceci est juste une préférence personnelle, basée sur l'expérience passée. J'utilise cette même approche avec Perl DBD.
Je me demande ce que Tom Kyte (asktom.oracle.com) a à dire sur ce sujet ?
