SQL vs. I/O natif

les procédures SQL.

Soyons sceptiques face aux programmeurs qui estiment que l’I/O natif est souvent supérieur à SQL. IBM améliore continuellement la performance de SQL sur l’iSeries, et si SQL a été généralement plus lent que l’I/O natif par le passé, il est peu probable que cela reste vrai aujourd’hui.

La performance SQL dépend de nombreux facteurs, y compris le modèle de la base de données et la qualité du code SQL. Mais la performance est rarement un facteur décisif pour choisir telle ou telle technologie d’I/O. Dans un contexte interactif, il est peu probable qu’une différence quelconque entre SQL et l’I/O natif soit humainement perceptible. En mode batch, SQL (conçu pour travailler avec des ensembles de données) devrait surclasser l’I/O natif.

On le voit, le choix entre l’I/O natif et SQL se résume encore une fois à la question suivante : lequel favorise le plus la compacité de compréhension. A première vue, on pourrait penser que la syntaxe simple de l’I/O natif ferait pencher la balance en sa faveur. Pourtant, de bonnes raisons plaident pour SQL. Pour en juger, nous devons regarder au-delà de l’instruction d’I/O elle-même, pour nous intéresser à sa place dans le code et à la conception générale du programme.

Deux différences cruciales entre SQL et l’I/O natif affectent la manière dont chacun peut contribuer à compacter le code et à structurer un programme. La première est que SQL peut inclure tous les critères de sélection de données dans l’instruction Select, tandis que l’I/O natif est limité à une sélection par clé et que d’autres étapes post-extraction devraient être effectuées pour mener des tests supplémentaires.

Cela résulte en une fonction commune du code RPG traditionnel utilisant l’I/O natif : les lectures et chaînes sont suivies de tests conditionnels, ‘iters’ et ‘leaves’. La seconde différence est que SQL peut joindre deux tables ou plus dans une seule instruction Select, tandis que l’I/O natif doit avoir une opération d’I/O séparée pour chaque accès à la table. Cela résulte en une autre fonction courante du coding RPG traditionnel : une opération read suivie de tests, suivis d’une suite de chains, chacune ayant sa propre batterie de tests. Quand cet accès aux données fichier par fichier avec des tests de condition s’entremêle avec la logique de gestion, nul ne s’étonnera que les programmes RPG classiques semblent coûteux à maintenir ! Il existe un meilleur moyen.

Par nature, SQL est plus compact que l’I/O natif, parce qu’il contient luimême ses tests conditionnels et qu’il peut joindre des fichiers multiples. Quand cette fonction compacte de SQL est combinée avec des procédures d’I/O ségréguées dans une structure de programme hautement modulaire, il en résulte une structure de code plus élégante.

Mais il y a plus : le curseur. Outre l’extraction d’une seule ligne de données à partir d’une ou plusieurs tables, SQL peut aussi produire un jeu de résultats à lignes multiples : en fait, un fichier virtuel. En RPG, on appelle cela un curseur. Une fois qu’il est produit (par l’instruction Select), vous pouvez utiliser une procédure fetch pour atteindre les données au moyen du curseur, ligne par ligne. Un programme RPG classique comporte une boucle où un read est suivi de tests et de chains et d’autres tests. Mais un programme RPG New Style effectue une procédure chargée de produire un curseur, puis boucle au travers du curseur comme s’il s’agissait d’un fichier préfiltré, comme le montre le fragment de code de la figure 2.

Il est vrai que, dans bien des cas, vous pouvez obtenir les avantages de la fonction curseur SQL par l’utilisation de fichiers logiques ou de la commande OpnQryF. Cependant, vous devriez lui préférer fortement SQL parce que c’est la direction stratégique de l’accès d’I/O sur l’iSeries, tandis que la commande OpnQryF et les fichiers logiques joints ne sont pas stratégiques et seront de plus en plus délaissés au fil du temps. Il est probable que les nouveaux développeurs seront bien plus à l’aise avec SQL qu’avec les fichiers logiques joints ou OpnQryF. De plus, SQL procure trois avantages importants : c’est un standard IBM et général, il est beaucoup plus fonctionnel, et il vous permet d’en faire beaucoup plus en programmation avec des valeurs de substitution de requêtes et SQL dynamique. (Pour plus de détails sur ce sujet, voir « SQL vs. OpnQryF – The Battle Continues », à mcpressonline.com/mc?1@79.FyB1cFwnZFq.0@ .6ae45a2d – l’enregistrement gratuit est nécessaire.)