Coexistence entre SQL basique et traditionnel

d’abord, voyons une instruction SQL que l’on peut utiliser avec des objets base de données traditionnels, y compris des fichiers physiques et logiques définis par DDS. La figure 5A recense les instructions DDL SQL importantes et les objets base de données respectifs que l’on peut référencer avec elles.

En général, les instructions DML SQL ne peuvent pas accéder aux fichiers logiques multiformats ou aux fichiers DDM. Les instructions Declare Cursor, Delete, Insert, Select Into, Update et Values peuvent toutes accéder à un fichier physique décrit par programme ou décrit en externe, ou à un fichier logique en format unique (single-format). Avec la commande OvrDbF (Override with Database File), on peut aussi rediriger ces instructions vers un fichier ou membre différent. L’instruction Lock Table peut allouer un fichier physique décrit par programme ou décrit en externe.

Pour aborder l’autre face du problème, dans la figure 5B, j’ai recensé des fonctions traditionnelles importantes et les objets SQL respectifs que l’on peut référencer avec elles.

En ce qui concerne la manipulation de données, les instructions d’I/O HLL et la commande OpnQryF (Open Query File) peuvent référencer une table, une vue ou un index SQL. Notons cependant que l’accès aux vues SQL ne peut se faire que dans l’ordre d’arrivée parce que les vues n’ont jamais un chemin d’accès indexé qui leur soit associé.

De plus, un programme HLL ne peut accéder à aucun objet SQL dont une colonne est déclarée de type LOB (large object) (c’est-à-dire, BLOB, character large object –CLOB -, ou DBCLOB, double-byte character large object), un type de données défini par l’utilisateur (UDT, user-defined data type), ou un DataLink. Pour accéder à une table ou une vue de base qui a un ou plusieurs de ces types de colonnes, on peut créer une vue (sur la table ou vue restreinte) pour exclure ou isoler les types de colonnes non supportés.

On peut utiliser les commandes AlcObj (Allocate Object) et DlcObjt (Deallocate Object) sur des tables, des vues et des index. On peut aussi utiliser AlcObj et DlcObj sur les objets OS/400 correspondants pour la plupart des autres objets SQL (par exemple, le programme créé par une instruction Create Trigger).

On le voit, on dispose d’une grande souplesse pour utiliser soit des fonctions traditionnelles, soit des instructions SQL, pour définir, contrôler, et manipuler tous les genres d’objets base de données. Les discordances à l’exécution les plus notables entre les approches SQL et base de données traditionnelles, se situent dans trois domaines :

• SQL ne permet pas d’accéder aux fichiers logiques multiformats. Pour d’anciens fichiers, cela peut être fâcheux. Toutefois, les fichiers logiques multiformats n’ont jamais été une bonne technique iSeries (ou AS/400 ou S/38), aussi vaut-il mieux s’en débarrasser au profit d’une meilleure alternative SQL.
• SQL ne supporte pas en mode natif les fichiers multimembres, même si l’instruction SQL Alias et la commande CL OvrDbF offrent des solutions convenables. Si l’on veut remplacer un fichier physique multimembre par des objets SQL, on a généralement besoin d’une table SQL pour chaque membre existant. Il faut modifier les commandes OvrDbF du code existant pour utiliser le paramètre ToFile pour rediriger vers les nouvelles tables (fichiers), au lieu d’utiliser le paramètre Mbr pour rediriger vers des membres spécifiques.
• SQL n’a pas d’équivalent direct des fichiers logiques indexés. Ce dernier point est de loin le problème le plus fréquent et le plus délicat que j’aie rencontré pour des entreprises désireuses de passer de DDS à SQL. En effet, on ne peut pas remplacer des fichiers logiques indexés par des alternatives SQL sans remplacer l’I/O HLL qui accède au fichier. Je reviendrai plus en détail sur ce sujet délicat dans la prochaine section.