SQL Server vu par Christian Robert

Team System Database : Quelques conseils pour importer ses données et gérer les références

Dans ma période d'usage intensif de la dernière version de Team System Database Edition (GDR), voici les quelques points que j'ai pu rencontrer sur des grosses bases de données et qui pourrait vous servir aussi.

1. Supprimer les références de la base vers elle-même

Les MaBase. / "MaBase". / [MaBase]. S'ils sont présent dans le code de base de données sont à proscrire. En effet c'est la cause numéro 1 des avertissements et erreur de l'outil. Ces références sont par ailleurs totalement inutiles dans la base elle-même et empêche la compilation du projet lorsqu'elles sont présentes dans des vues et des fonctions.

• Moralité la première étape après l'import est de faire un gros « Remplacer » de toutes ces références par rien !

2. Les références vers d'autres bases de données

Si vous travaillez avec plusieurs bases de données qui pointent les unes vers les autres, vous vous rendrez vite compte que les regrouper au sein d'un même projet pose pas mal de problème de références, et si celles-ci sont circulaires.... Heureusement des solutions existent. Sachez comme évoquez dans le point ci-dessus que seules les références des fonctions et vues empêchent la compilation.

• Commencer par les bases ayant le moins de références externes ou pas du tout (merci Guillaume pour le conseil)
• Commentez les portions de code rebelle en mettant un tag à vous pour les retrouver et les dé-commentés quand vous aurez ultérieurement résolu la référence.

3. Les références circulaires

Si vous avez fait comme ci-dessus vous devriez être capable de compiler un projet, une fois ceci fait :

• Référencez uniquement les fichiers .dbschema et pas les projets
• Indiquez dans les propriétés de la référence d'ignorer les avertissements de la référence elle-même (l'outil ne regardera que les référence de don projet pas plus loin)

4. Les références qui résistent toujours après çà

Une fois tous les projets liée entre eux ils vous restera quelques références rebelles, telles que les références à certains objets système (sys.*), les tables et procédures situés dans master, msdb. Et si vous créez des objets directement dans tempdb non préfixés par # ou ## les tables, procédures, etc. qui ont été crée dans tempdb aussi.

• Créez un projet serveur dans lequel vous scriptez le contenu de la base de données système contenant ces objets
• Si vous utilisez ces 3 bases de données systèmes, essayez autant que possible de les regrouper au sein d'une même base (le refactoring vous aidera au besoin).

5. Comptes de sécurités et droits d'accès

Les permissions peuvent être stockées dans les propriétés de la base de données, si vous le choisissez. J'ai une opinion assez mitigé du choix à faire étant données qu'il faut distinguer les comptes nécessaires à l'application de ceux nécessaires aux administrateurs et développeurs.

• Conservez uniquement les utilisateurs nécessaires à l'application dans la base de données
• Attribuez de préférences les droits à des rôles et mettez les scripts de création des logins / utilisateurs dans un projet serveur ou à l'inverse regroupez tout dans la base de données. Quitte à créer vos scripts personnalisés.
• Autant que possible bannissez les AUTHORIZATION farfelus (propriétaire des objets) et confiez les tous au bon soin de [dbo] comme propriétaire.

6. Les objets orphelins

Après tout çà vous aurez forcément des références toujours non valides, mais celles restant devraient être des « vieux » morceaux de code ayant de réelle références invalide.

• Testez donc dans votre base de données originale pour bien être certains que le code est bien un « oublié » de la base

En suivant ces conseils vous devriez être armé pour le pire ;o)

Bon import...