Harmonie des bases de données : coexistence entre 'tratidionnel' et SQL

par Paul Conte Mis en ligne le 22/02/2006 - Publié en Juillet 2005

En tant que développeurs iSeries, vous savez que SQL est désormais le seul langage stratégique de définition et d’accès aux bases de données d’IBM pour DB2 for iSeries. Dans l’ensemble, SQL est supérieur à l’approche « traditionnelle » de DDS pour la définition de données et les opérations d’I/O intégrées HLL. SQL est un langage standard compatible avec de nombreux outils et ressources de formation. Mieux encore, le nouveau support DB2 dans l’OS/400 rend SQL plus performant et SQL offre un large éventail de fonctions dont DDS ou l’I/O HLL sont dépourvus.Bien entendu, certaines fonctions habituelles sont absentes dans SQL (comme les fichiers multimembres) et, pour certains types d’accès aux bases de données, l’I/O classique demeure plus rapide que SQL. Sans entrer dans les détails, disons simplement que vous devriez généralement utiliser SQL, dans la mesure du possible, pour définir de nouveaux objets base de données et pour l’accès aux bases de données dans de nouvelles applications. Mais en tenant compte de certains cas exceptionnels où les bonnes vieilles méthodes resteraient de mise.

La question plus délicate est de savoir comment commencer à utiliser SQL avec une base de données existante qui comporte de nombreux fichiers définis par DDS et de nombreuses applications qui utilisent l’I/O HLL. Cet article examine de manière concise et rapide les problèmes de « coexistence » potentiels quand on utilise des méthodes traditionnelles et SQL dans le même site.

Lorsqu’on compare SQL aux approches traditionnelles, il faut bien comprendre que SQL inclut à la fois un langage de définition de données (DDL, data definition language - par exemple, l’instruction Create Table) et un langage de manipulation de données (DML, data manipulation language – par exemple, l’instruction Update). SQL inclut également ce que l’on appelle parfois des instructions de contrôle de données (comme Grant et Revoke), ainsi que quelques instructions de programmation polyvalentes pour définir le corps des procédures stockées, des fonctions définies par l’utilisateur, et des déclencheurs.

En revanche, les approches traditionnelles utilisent plusieurs langages distincts – dont DDS et HLL (comme RPG IV, ILE, Cobol) – qui incluent des extensions d’I/O pour supporter les fichiers base de données et des commandes CL, comme celles que l’on voit dans la figure 1.

Comme à la fois les fonctions traditionnelles et SQL s’appuient sur le même noyau de possibilités OS/400, vous pouvez aussi combiner librement des techniques SQL/400 et traditionnelles. Ainsi, vous pourriez utiliser Create Table pour créer une table de base de données puis utiliser la commande GrtObjAut (Grant Object Authority) pour contrôler l’accès.

Si l’on envisage SQL, il est bon de connaître les fonctions que permet l’approche traditionnelle et pour lesquelles il n’existe pas d’alternative SQL complète. La liste de la figure 2A vous aidera à éviter les écueils et à mieux prévoir la coexistence. A titre de comparaison, la figure 2B offre la liste des fonctions SQL non disponibles avec les méthodes utilisant des bases de données traditionnelles.

L’importance d’un élément particulier dépend, bien entendu, des besoins de l’application. Mais, en général, on peut dire que les fichiers de référence de champs sont le grand absent dans la définition de données SQL. Les types définis par l’utilisateur SQL permettent de réutiliser des définitions dans une certaine mesure, mais sans égaler la fonction DDS, qui est une aide au développement (pas à l’exécution) appréciable. Des outils, comme iSeries Navigator, qui fournissent un raccourci ponctuel pour définir une nouvelle colonne (champ) SQL en se basant sur une colonne existante, sont inadéquats parce que les changements apportés à la colonne référencée ne peuvent pas se propager automatiquement aux autres colonnes qui étaient basées sur la colonne référencée.

Une alternative raisonnable quand on utilise SQL, consiste à se servir d’un outil de conception de base de données et de génération de code SQL qui permet de maintenir les définitions, y compris un « dictionnaire » de « types » de colonnes courantes liées dynamiquement aux définitions de tables. Mais cette solution pose un problème : l’outil doit également supporter le SQL complet pour la syntaxe iSeries.

Il existe un autre moyen : utiliser un préprocesseur opensource ou maison, capable de lire des définitions de tables SQL qui utilisent un « type » de colonne (comme $Currency) et sortir un code SQL dont le type de colonne aura été remplacé par les caractéristiques de colonne appropriées. Bien que cet outil ne soit pas difficile à créer, on préfèrerait qu’IBM règle le problème de manière plus systématique. Bon gré mal gré, IBM devrait reconnaître que le manque de remplaçant pour les fichiers de référence de champs est l’un des principaux obstacles à l’adoption généralisée de SQL DDL sur l’iSeries.

Le fait que j’aie inclus des éléments du chemin d’accès dans la seconde liste de la figure 2A ne signifie nullement que SQL ne peut pas extraire des lignes par la logique select/omit ou rangées par valeur absolue. SQL peut bien sûr accéder aux données par ces diverses méthodes, mais l’instruction SQL Create Index ne permet pas de créer un objet index (c’est-àdire un chemin d’accès) qui possède ces propriétés. (Pour d’autres considérations sur ce sujet, voir aussi l’encadré « Accès SQL des tables « clonées » et des fichiers multimembres » ci-après.)

La figure 3 récapitule les objets base de données traditionnels et SQL comparables. La figure 4A fournit une liste aide-mémoire aux développeurs qui maîtrisent bien les interfaces base de données traditionnelles et désireux de connaître les techniques à utiliser en SQL. Cette liste n’est nullement exhaustive et j’ai exclu bon nombre d’opérations comparables évidentes, comme le fait que l’instruction SQL Insert soit comparable à une instruction Write de RPG IV ou Cobol. J’ai essayé de mettre dans la liste des éléments sur lesquels les programmeurs s’interrogent le plus souvent, d’après mon expérience. La figure 4B offre une liste d’alternatives classiques pour certaines techniques base de données SQL.