Evitez les complications

compiler un membre source SQLRPGLE en utilisant Create SQL ILE RPG Object (CRTSQLRPGI), qui exécute le précompilateur SQL avant d’exécuter le compilateur RPG.

Les valeurs que vous sélectionnez pour les diverses options de la commande CRTSQLRPGI contrôlent le précompilateur SQL et peuvent influencer la façon dont votre code SQL imbriqué s’exécute. La figure 6 donne la liste de certaines options CRTSQLRPGI, parmi les plus importantes, et leurs paramètres recommandés. Vous trouverez des informations détaillées sur toutes les options du précompilateur dans l’information de référence CL pour CRTSQLRPGI. Traiter les listes de bibliothèques est de loin la plus grande difficulté que vous rencontrerez avec SQL dans un environnement System i.

Pour les programmes qui incluent SQL imbriqué, la solution la plus simple est le plus souvent de choisir *SYS comme convention de nommage SQL. Vous obtiendrez ainsi des résultats identiques ou presque à ceux des listes de bibliothèques auxquelles vous étiez habitués avec les applications RPG traditionnelles. En règle générale, utilisez le nommage système (*SYS) quand vous créez une application qui tourne entièrement sur le System i et qui utilise les langages traditionnels de ce dernier. Utilisez le nommage SQL (*SQL) si votre programme SQL imbriqué peut être appelé par une composante de code non spécifique à System i, comme une méthode Java. Lorsqu’on crée des applications qui incluent SQL imbriqué, la performance est aussi un aspect primordial.

En théorie, le simple fait d’ajouter SQL imbriqué au mix d’outils de développement disponibles devrait améliorer la performance. Mais, bien entendu, ce n’est pas aussi simple. SQL peut même dégrader la performance dans des cas où l’accès à la base de données en mode natif est plus efficace, ou si votre SQL est écrit d’une manière qui empêche l’optimiseur de requêtes (le moteur de requête i5/OS) d’exécuter votre code efficacement. Préparez-vous donc à une certaine analyse de performance, particulièrement pour des applications qui comportent des requêtes complexes traitant de grandes quantités de données.

Heureusement, i5/OS possède de nombreux outils capables de mesurer la performance SQL et de déterminer les éventuels goulets d’étranglement. Pour plus d’informations à ce sujet, voir le redbook OnDemand SQL Performance Analysis Simplified on DB2 for i5/OS in V5R4 (SG24-7326). Enfin, comme pour toute autre application, évitez de coder en dur et réduisez au minimum tout code redondant dans vos programmes SQL imbriqués.

Pour atteindre ces objectifs, il vous faudra peut-être recourir à des programmes de service, des procédures stockées et d’autres techniques qui segmenteront votre code en composantes gérables et réutilisables. Voir l’article « Application iSeries : modularisation » (octobre 2005, www.itpro.fr Club Abonnés) pour quelques suggestions générales en la matière.