à  celui de la ou des clés les plus courantes. Pour cela, on peut trier le fichier
ou le réorganiser dans l’ordre dans lequel il est le plus souvent traité, puis
le traiter séquentiellement. La plupart des gens ne le font pas. Ils passent donc
à  côté de grandes possibilités d’amélioration de performances, particulièrement
dans le cas de grands fichiers dont il faut traiter tous les enregistrements.

Certains clients rétorquent qu’ils utilisent déjà  le traitement séquentiel. Mais
après examen des fichiers utilisés dans un job modèle, on constate que ce traitement
séquentiel ne s’applique qu’à  leurs fichiers logiques. Les fichiers logiques lisent
un enregistrement avec une valeur clé n, puis l’enregistrement avec une valeur
clé (n + 1), et ainsi de suite. Dans le même temps, les données qui constituent
les enregistrements du fichier physique sont disséminées sur l’ASP. L’analyse
des performances de ces jobs révèle généralement une lecture physique pour chaque
lecture logique (c’est-à -dire pratiquement pas de blocage).

Pour voir si cette situation s’applique à  un système, il faut examiner le traitement
du fichier applicatif. Si le fichier physique peut être trié dans l’ordre de la
clé de traitement et lu séquentiellement (en utilisant le blocage) et si on peut
utiliser une description de fichier distincte pour la sortie, on pourra peut-être
améliorer les performances.
Les applications générées par la plupart des L4G ne traitent pas de fichiers physiques
; elles travaillent exclusivement avec des fichiers logiques et ne se soucient
pas de trier les données réelles dans l’ordre donnant le traitement le plus performant.
Si le code fonctionne, on s’en tient là . La vraie optimisation des performances
de la base de données n’est pas d’actualité avec du code écrit en L4G. En appliquant
certaines des techniques de cet article, on pourra néanmoins améliorer leur débit
batch. Attention quand même : si on modifie le code généré par le L4G, l’intégrité
du traitement n’est pas garantie.