Des solutions aux problèmes fréquents

/>Dans SQL Server 2000, vous pouvez créer des types de données définis par l’utilisateur (UDT) au moyen de la procédure stockée sp_addtype :

EXEC sp_addtype CtemperatureInt,
    int, ‘NOT NULL’
EXEC sp_addtype FtemperatureInt,
    int, ‘NOT NULL’

Malheureusement, SQL Server convertit automatiquement les valeurs des deux types de données cidessus selon les besoins ; ainsi, un UDT n’est pas la solution pour un typage fort. Néanmoins, la différence dans le type de données apparaît pendant la comparaison au niveau schéma. Par ailleurs, SQL Server 2005 promet une prise en charge plus souple des types de données, contribuant ainsi à réaliser un typage fort.

L’utilisation d’UDT ajoute une documentation implicite à vos schémas en fournissant un nom plus descriptif et plus spécifique pour les données. Ils contribuent également à la cohérence sur le fait qu’un champ puisse prendre ou non une valeur NULL. Un inconvénient de ces types dérivés réside dans le fait qu’il peut être difficile de reconnaître le type de données de base en examinant le nom du type dérivé. Vous pouvez résoudre ce problème en plaçant en suffixe le nom du type au type de base, comme l’illustre l’exemple de code UDT ci-dessus.

Vous pouvez également identifier certaines différences d’interprétation en examinant les données. La température corporelle, par exemple, doit être située dans une plage délimitée par des valeurs sensées. Ainsi, une valeur de température corporelle de 100 °C n’a assurément pas sa place dans une base de données médicale.

Dans ce type de situation, vous pouvez configurer des contraintes d’intégrité de base de données. Celles-ci peuvent contribuer à détecter l’insertion de données non valides dans une table à la suite d’une fusion de tables.

Pour configurer une contrainte de vérification portant sur une colonne de températures dont le type est CTemperatureInt, il est possible d’inclure le code suivant dans la déclaration de la table :

temperature Ctemperature CHECK
    (temperature >10 AND
    temperature <43)

L’insertion d’une valeur incorrecte aboutira à une erreur, comme celle illustrée à la figure 4. Fréquemment, un schéma est déjà donné, comme c’est le cas au cours d’une migration à partir d’applications propriétaires. L’ajout de contraintes de vérification temporaires peut aider à identifier les problèmes dans les scripts de migration.

Les déclencheurs constituent une alternative aux vérifications. Ils considèrent la valeur des champs insérés ou modifiés, puis annulent la transaction en présence de valeurs incorrectes. Vous pourriez remplacer la contrainte de vérification précédente pour les insertions de lignes unique par un déclencheur tel que celui illustré dans le listing 1. Les contraintes de vérification sont généralement plus efficaces lorsque la majorité des insertions réussit et les déclencheurs sont plus performants lorsque la majorité des insertions contient des valeurs non valides.

SQL Server 2005 va introduire des déclencheurs DDL (Data Definition Language). Cette nouvelle version sera capable d’exécuter automatiquement de tels déclencheurs DDL en cas de changement des schémas de base de données. Les DBA auront alors le moyen d’appliquer des règles élémentaires liées aux schémas sur la base de données. De telles règles peuvent inclure une documentation obligatoire, le recours à certains types de données et l’utilisation obligatoire de contraintes de vérification.

Dans de nombreux cas, même les contraintes de vérification ou les déclencheurs ne sont d’aucune utilité car les valeurs de deux interprétations peuvent avoir des plages de valeurs qui se superposent. Les différences de numérotation des étages entre le Royaume-Uni et les Etats-Unis, ou encore la représentation monétaire de différentes devises en constituent deux exemples. Si vous n’utilisez pas des types de données dérivés pour capturer cette dissonance de la sémantique des données, une bonne documentation des schémas de base de données constitue le dernier recours d’un DBA.
Les outils de comparaison automatique ne détectent pas ces conflits. Par conséquent, à moins de savoir que deux bases de données utilisent le même schéma et qu’elles sont mises à jour exactement de la même manière, vous devez contrôler plutôt deux fois qu’une le script de fusion fourni par votre outil de comparaison de base de données et le rapprocher de la documentation des bases de données.