Traiter des fichiers logiques indexés

les avantages et les étapes nécessaires pour exploiter cette tactique, voir les articles « Comparaison des performances entre fichiers définis par DDS et fichiers définis par SQL » et « Remplacer un fichier physique DDS par une table SQL ».

Mais si l’on veut remplacer les fichiers logiques par des objets SQL, il faut voir de plus près comment les fichiers logiques candidats sont définis. La figure 6 donne la liste de différentes caractéristiques des fichiers logiques et les exigences à satisfaire pour les remplacer par des objets SQL. On remarquera que toutes les difficultés viennent de l’accès par l’I/O HLL traditionnel. Si l’on remplace tous les programmes qui accèdent à un fichier logique en même temps que l’on remplace le fichier, on peut simplement remplacer le fichier par une vue SQL et utiliser DML SQL pour y accéder.

Pour les rares cas où un fichier logique n’a pas de logique clé ou select/omit et ne recouvre qu’un membre de fichier physique, on peut généralement remplacer le fichier logique par une vue SQL équivalente et, dans les programmes HLL, traiter simplement la vue de la même manière que le fichier logique original (voir la ligne A de la figure 6).

Même si le fichier logique a une logique select/omit, tant qu’il n’a pas de champs clés et qu’il ne recouvre qu’un membre de fichier physique (ligne B), on peut utiliser une vue SQL équivalente. Mais il faut savoir que la sélection de lignes pour des vues SQL est toujours dynamique, alors qu’il est courant pour des fichiers logiques d’avoir une sélection statique en utilisant un chemin d’accès select/omit associé.

Il existe un type de fichier logique beaucoup plus courant que ceux des cas précédents. C’est celui qui partage le format d’enregistrement sous-jacent du fichier physique (c’est-à-dire que le DDS fichier logique n’a pas de définitions de champs explicites) et qui définit simplement un chemin d’accès indexé (ligne C). Quand un tel fichier recouvre un seul membre de fichier physique et n’a pas de logique select/ omit (cas le plus courant), la solution de bon sens consiste à remplacer simplement le fichier logique par un index SQL défini sur la table SQL qui remplace le fichier physique original. Bien entendu, l’index doit avoir les mêmes spécifications de clés que le fichier logique. Vos programmes HLL peuvent alors simplement ouvrir l’index SQL comme si c’était un fichier logique indexé (ce qu’il est en réalité sous le capot).

Malheureusement pour les sites souhaitant faire migrer leurs objets base de données vers SQL, nombreux sont les fichiers logiques qui n’appartiennent à aucune des catégories précédentes. Pour les fichiers indexés qui ont des définitions de champs mais pas de logique select/omit et qui ne recouvrent qu’un seul membre de fichier physique, certains programmes pourront parfois utiliser un index SQL, comme décrit précédemment, pour autant qu’il soit facile d’adapter le programme pour lire simplement le format d’enregistrement entier.

Pour tous les autres cas, la seule solution consiste à remplacer l’I/O HLL par DML SQL, ce qui n’est pas une mince affaire. La plupart des sites sur lesquels j’ai travaillé laissent purement et simplement ces fichiers logiques en place. (Comme expliqué dans l’article « Remplacer un fichier physique DDS par une table SQL », il se peut que vous vouliez ou deviez recréer ces fichiers logiques après avoir remplacé le fichier physique sous-jacent par une table SQL.