UDB/400 en perspective

Hoffman : Qu’est-ce qu’une
fonction définie par l’utilisateur (UDF, user-defined function) et
qu’apporte-t-elle aux développeurs ? On serait tenté de répondre qu’elle
permet de faire pratiquement n’importe quoi, mais ce n’est pas si simple !

Milligan : On peut voir les UDF
comme une interface permettant d’étendre et de personnaliser le langage SQL
en fonction des besoins. L’ensemble des fonctions prédéfinies, comme
Substring et Absolute Value, qui accompagnent une base de données SQL, ne
sauraient répondre à  toutes les exigences. Avec les UDF, on peut écrire ses
propres fonctions et les utiliser dans des instructions SQL suivantes, comme on
le ferait de toute autre fonction système. On peut utiliser les UDF de
multiples façons. On pourrait par exemple créer des fonctions particulières
calculant la taxe d’hébergement à  l’hôtel ou la taxe sur les salaires pour
une ligne donnée. Mais il faut éviter de confier aux UDF des actions de longue
durée, comme des sauvegardes d’objets sur bande ou des mises à  jour batch.

Anderson : Supposons que l’on
veuille afficher une liste de toutes les tables présentes sur un PC, avec leurs
tailles. A l’heure actuelle, cette tâche n’est pas simple si l’on
souhaite simplement obtenir l’ensemble des résultats. On peut certes
interroger les tables du catalogue, mais comment obtenir leurs tailles ? On
peut aussi écrire une procédure cataloguée simple pour sortir et, à  partir
d’un nom de table et d’un nom de bibliothèque, obtenir la taille à 
l’aide d’une API. Mais désormais avec les UDF, on peut coder une fonction
qui s’interface avec la même API et inclure simplement cette fonction dans la
requête du catalogue de la base de données. De par le passé, il aurait fallu
appeler l’API de taille séparément de l’interrogation des catalogues.

Milligan : Une UDF est utile si
l’on utilise une fonction SQL sur un autre système ou une autre base de données
non encore prise en compte sur l’AS/400. Ainsi, Mark a créé récemment une
UDF pour Soundex, un algorithme permettant de convertir des chaînes de texte en
chaînes phonétiques utilisables pour la comparaison et la commande de données
caractères. Comme l’AS/400 ne supporte pas Soundex; mais on peut utiliser le
langage C ou un autre langage évolué pour mettre en oeuvre cet algorithme avec
une UDF.

Guthrie : Avec l’exemple Soundex,
on définirait probablement un type défini par l’utilisateur (UDT,
user-defined type) comme celui de Soundex, qui collaborerait avec les UDF.
Existe-t-il une règle empirique de performances permettant d’évaluer ce
qu’il faut inclure dans des UDF ?

Anderson : Dans l’exemple Soundex,
on pourrait établir un UDT distinct (avec un type de données défini à  partir
d’un type de données fourni par le système) pour définir la sortie de la
fonction Soundex. Mais, en principe, Soundex est utilisé dynamiquement sur
n’importe quelle chaîne de caractères, de longueur fixe ou variable, ou même
un grand objet (LOB, large object). Le rôle de base de Soundex consiste à 
prendre le texte et à  fournir sa représentation phonétique, puis à  afficher
la forme sonore d’un texte particulier. Donc, on n’a pas vraiment besoin
d’un UDT pour l’utiliser, bien que ce soit possible. (Pour en savoir plus
sur les possibilités des UDF et des UDT, voir l’article "Operations
Navigator passe la quatrième pour UDB/400"). 

Guthrie : Je pose la
question parce qu’il semble que vous souhaitiez stocker le hachage avec une
table pour des considérations d’accès.

Anderson : Bien vu. Si
l’on voulait utiliser fréquemment le hachage phonétique, il serait bon
d’avoir un UDT distinct contenant les résultats de la fonction Soundex. On
calculerait le hachage, qui serait ensuite stocké dans la base de données
comme une colonne avec un UDT (peut-être un type de données hachage Soundex).
Mais, après cela, on interrogerait simplement cette colonne directement.