Considérations

moment de l’insertion. Par le passé, peut-être avonsnous simplement ignoré les erreurs de données décimales. Maintenant il vous faudra peut-être changer les programmes qui exécutent les opérations d’écriture, pour traiter de nouvelles exceptions.

La suppression d’un mot-clé REFFLD pendant la conversion de PF à LF entraînera l’impossibilité de mener des recherches « là où c’est utilisé », d’après l’information de référence des champs. Je vous conseille de pratiquer l’ingénierie inverse de vos fichiers de référence de champs existants, en tables SQL. Sachant que vous perdrez tous les motsclés associés à la présentation, vous ne devez pas supprimer les fichiers de référence des champs originaux. Je vous conseille d’utiliser la nouvelle table de fichiers de référence de champs SQL pour ajouter de nouvelles colonnes, puis d’utiliser iSeries Navigator pour référencer ces colonnes lors de la création ou du changement des tables SQL.

Tous les fichiers écran et fichiers d’impression continueront à référencer les fichiers de référence de champs originaux. Si ces types de fichiers référencent des fichiers physiques réels avec des données applicatives, il faut les modifier pour référencer un fichier de référence de champs. (Pour plus d’informations, voir l’encadré « Fichiers de référence de champs »)

A partir d’ici, je recommande de créer tous les nouveaux fichiers physiques avec des instructions SQL CRETA TABLE DDL. En outre, tout l’accès HLL aux fichiers physiques créés par DDL sera fait au moyen de fichiers logiques DDS. Par ailleurs, forts de vos connaissances en partage de chemin d’accès, veillez à créer un index SQL avec les mêmes clés que le fichier logique que vous êtes en train de créer. Prenez aussi pour habitude de ne spécifier dans le fichier logique que les champs nécessaires au programme.

Le plus dur à ce stade est de résister à la tentation de changer la base de données. Nous voulons tous utiliser le support de colonne d’identité, l’intégrité référentielle (RI, referential integrity), renommer ou redimensionner des colonnes, changer des attributs, et bien d’autres choses. Sachez que tout changement apporté à la base de données peut entraîner des changements de format des fichiers logiques DDS, obligeant à recompiler.

Le remaniement d’anciennes bases de données créées par DDS ne consiste pas simplement à pousser un bouton, et ce n’est pas une opération qui se fait du jour au lendemain. Si c’était aussi simple, nous l’aurions tous fait depuis longtemps. Il faut bien comprendre les changements apportés à l’architecture de la base de données et connaître les avantages ou les inconvénients de la nouvelle architecture. Pour en savoir plus sur les différences entre les approches base de données « traditionnelles » (y compris DDS et HLL I/O) et SQL, lisez l’article « Harmonie des bases de données : coexistence entre le « traditionnel » et SQL ».

Avant d’entamer ce périple, je vous conseille de créer un poste d’architecte base de données (s’il n’existe pas déjà). En effet, il y aura beaucoup de décisions à prendre sur des sujets d’héritage, comme les fichiers multiformats et multimembres, les fichiers logiques select/omit, et les fichiers de référence de champs. Et aussi d’autres décisions quant à l’utilisation des colonnes d’identité, RI, sécurité au niveau colonne, support de grands objets, XML et autres.

De telles décisions ne peuvent pas être laissées à l’appréciation d’un programmeur d’applications ou d’un administrateur système. L’architecte base de données est l’élément de liaison entre ces deux entités. Bien entendu, cette personne pourra fournir des solutions base de données à la fois superbes et utiles, avec SQL.