Recommandations relatives aux schémas multiples dans une base de données

Si vous prenez en charge plusieurs environnements de développement ou de test en simultané dans le même système, vos applications peuvent être rédigées avec des noms de table non qualifiés. Lorsque des noms de table non qualifiés sont utilisés, plusieurs développeurs peuvent s'exécuter simultanément sur plusieurs exemplaires du même schéma de base de données avec des noms de qualificateur différents. L'utilisation de noms de table non qualifiés permet à plusieurs schémas d'environnement de test et de développement de coexister sur le même sous-système. Il convient d'adopter une approche structurée pour entretenir un tel environnement et pour assurer l'exécution de plusieurs instances d'une application sur la base de données et les packages associés.

Dans les environnements utilisant des bases de données DB2 for Linux, UNIX, and Windows, il est possible de consacrer une base de données entière à un seul environnement de développement ou de test. De même, si plusieurs instances d'une application partagent la même base de données dans un environnement DB2 for Linux, UNIX, and Windows, ou si plusieurs environnements de développement ou de test coexistent dans un même sous-système DB2 for z/OS, une convention de dénomination peut prendre en charge des environnements différents dans le même système.

La liste suivante décrit les recommandations à suivre en cas d'utilisation de plusieurs schémas au sein d'une base de données :
  • Pour assurer l'indépendance de l'environnement, la table ou d'autres objets de la base de données, le schéma et les packages doivent être isolés. Pour garantir l'isolation de la table, créez des schémas de table identiques avec différents ensembles de qualificateurs.
  • Lorsqu'un package est lié, l'option QUALIFIER peut être utilisée pour définir le schéma par défaut. Un environnement de développement peut contenir plusieurs packages portant le même nom, mais des paramètres de qualificateur différents. Outre l'option du qualificateur, d'autres conventions doivent être utilisées pour prendre en charge plusieurs packages portant le même nom de package. Vous pouvez utiliser deux options, des ID collection ou la gestion des versions du package.
    ID collection
    Les ensembles de package représentent des groupes de packages. Les ensembles permettent à plusieurs packages du même nom de coexister sur un même système. Les ensembles peuvent être considérés comme des conteneurs dans lesquels le caractère unique des éléments est préservé.

    Si des packages du même nom sont présents dans différents ensembles, les packages peuvent coexister sur le même système. L'utilisation d'ensembles peut permettre à de nombreux développeurs d'applications de travailler sur différentes versions d'une application, peuvent prendre en charge les tests et la production sur un même serveur et permettre un déploiement par phases et entièrement disponible d'une version de l'application.

    Dans le cas d'ensembles distincts, les applications devront définir la variable CURRENT PACKAGESET (ou CURRENT PACKAGE PATH sous DB2 for Linux, UNIX, and Windows, ou sous DB2 for z/OS). La définition de la variable peut être effectuée avec un paramètre de source de données WebSphere.

    Vous utilisez l'utilitaire pureQuery Configure avec l'option -collection pour définir l'ID collection.

    Conseil : Lorsque vous utilisez l'utilitaire Configure sur un fichier pureQueryXML, un ID collection est ajouté au fichier. Pour modifier l'ID collection dans un fichier configuré avec l'option d'utilitaire Configure -collection, vous devez aussi utiliser soit l'option Configure -setPreStatusOfAllPackages avec la valeur définie sur REQUIRED, soit l'option Configure -cleanConfigure avec la valeur définie sur TRUE.
    Versions de package
    La gestion des versions de package permet également d'obtenir les mêmes résultats. Comme dans le cas des ensembles distincts, des packages de versions différentes peuvent coexister, même s'ils figurent dans le même ensemble.

    Les versions d'un package peuvent présenter l'avantage de ne pas nécessiter un environnement particulier dans une source de données WebSphere ou une logique d'application. Pour la gestion des versions de package, une marque de cohérence dans le fichier pureQueryXML de l'application identifie la version correcte du package.

    Vous utilisez l'utilitaire pureQuery Configure avec l'option -pkgVersion pour définir la version du package.


Commentaires