code

SQL under control

Depuis quelques années, les ORMs (Object-Relational Mapping) ont permis aux développeurs « d’oublier », ou plutôt de masquer, la tâche d’écriture et de gestion du code SQL. Pour nous autres, développeurs .NET, je peux citer Entity Framework et Code Fluent. Ces outils permettent de gagner du temps (génération de codes automatiques par exemple) et offrent la possibilité de travailler avec des objets (contrairement à une base SQL qui est relationnelle).

Tout ceci est extrêmement pratique, mais cela ne représente qu’une infime partie de ce qu’est une base de données dans un projet informatique. Le modèle est une chose, mais il ne faut pas oublier les procédures stockées, les fonctions, les services brokers, la configuration… Tous ces éléments représentent notre référentiel. Il faut bien garder à l’esprit que ce référentiel va évoluer au fur et à mesure de l’avancement du développement du projet. Tout comme le code applicatif, il est donc très important, voire essentiel, d’avoir à disposition une « image » à jour de notre référentiel ainsi qu’un historique des modifications qu’on lui a fait subir. De plus, la possibilité de pouvoir manipuler et utiliser ce référentiel pour pouvoir le déployer facilement et rapidement vers un environnement est un atout indéniable.

Enfin, un projet de développement informatique se faisant rarement seul, il est nécessaire de pouvoir partager et synchroniser ce référentiel avec l’ensemble de l’équipe.

Pour cela, il existe bien sûr une solution et c’est l’objet de cet article : les projets SQL Server Database.

SQL Server Database, qu’est-ce que c’est ?

SQL Server Database est un type de projet Visual Studio, disponible à partir de la version 2010 de l’IDE (mais largement amélioré à partir de la version 2013), malheureusement méconnu et peu (ou mal !) utilisé. Il repose sur l’outillage SQL Server Data Tools (fourni par défaut à partir de Visual Studio 2013).
Dans les grandes lignes, ce type de projet va permettre de transformer votre base de données en une série de fichiers textes (.sql) la décrivant. Les intérêts de cette solution sont multiples :

⇒ Modification aisée (via des designers pour certains types de fichiers) directement dans Visual Studio ;
⇒ Intégration à Visual Studio et donc archivage simplifié ainsi que gestion de l’historique
⇒ Projet compilé et donc détection des erreurs au plus tôt (attention tout de même, ce mécanisme ne couvre pas tous les types d’erreurs) ;
⇒ Compatibilité avec la fonctionnalité « Code Analysis » de Visual Studio ;
⇒ Recherche !
⇒ Support de l’IntelliSense et la coloration syntaxique.

Je souhaite particulièrement insister sur l’aspect archivage avec un gestionnaire de code source. Cette fonctionnalité est particulièrement importante et ce pour plusieurs raisons :

⇒ Gestion simple de l’évolution du schéma de la base de données (de la même façon que pour le code source) ;
⇒ Maintien de la cohérence entre la BDD sur le serveur SQL et le projet Visual Studio ;
⇒ Maintien d’un historique des modifications et mise à disposition d’outils de comparaison et de rollback ;
⇒ Intégration de la documentation directement dans le code SQL ;
⇒ Dans le cas de TFS, liaison avec les WorkItems/Bug, ce qui permet de grouper un ensemble de modifications (par fonctionnalité par exemple).

Un projet SQL Server Database en détails

Je vais désormais essayer d’illustrer les différentes possibilités d’un projet SQL Server Database avec quelques exemples. Premièrement, la création du projet. Le template se trouve dans la rubrique « Other Languages » -> « SQL Server ».

paramètre sur un ordinateur

De base, le projet ne contient aucun élément. Je vous conseille d’ores et déjà de créer des dossiers pour mieux organiser votre futur référentiel de base de données. J’ai pour habitude de créer les dossiers suivants :

⇒ Comparisons
⇒ Functions
Migrations : J’y stocke les scripts SQL me permettant de passer ma base d’une VX vers une VX+1, et ce pour chaque nouvelle version
Security : Contient les scripts liés à la gestion des droits
⇒ Snapshots
⇒ Stored Procedures
⇒ Tables
⇒ Views

Bien évidemment, libre à vous d’organiser comme bon vous semble votre projet.
Une fois le projet créé, nous pouvons passer à sa configuration. Un projet SQL Server Database permet de paramétrer très finement de nombreux réglages. Ces réglages sont accessibles à partir des propriétés du projet.

paramètre sur un ordinateur

A ce niveau, les réglages essentiels touchent à la version SQL cible et au schéma par défaut. Mais en cliquant sur le bouton « Database Settings », une fenêtre bien plus complète (et complexe !) s’affiche.
Les 3 onglets concernent des réglages assez avancés à propos de la base de données.

paramètre sur un ordinateur

Une fois notre projet configuré, il est désormais temps de créer notre première table. Pour ce faire, Visual Studio met à notre disposition un éditeur graphique. Celui-ci est extrêmement pratique car il permet de visualiser rapidement l’ensemble des colonnes dans l’encart en haut à gauche et les éléments spécifiques (clés primaires/étrangères, index) en haut à droite tout en ayant un visuel sur le code SQL généré en bas de l’écran.

code sur ordinateur

Pour cet exemple, j’ai choisi de créer une table simple avec 5 colonnes, 1 clé primaire indexée et 1 clé étrangère.

Il est très important de noter que les projets SQL Server Database fonctionnent sur le modèle déclaratif, c’est-à-dire que l’on va écrire des scripts permettant de dire comment la base doit être et non pas comment y arriver. Autrement dit, on va écrire uniquement du code SQL de type « CREATE… » et pas de « DROP » ou d’ »ALTER ». C’est le moteur de Visual Studio (via le processus de déploiement) qui va se charger de faire le travail de comparaison pour obtenir l’état voulu.

A noter, il est possible de réaliser des requêtes entre plusieurs bases de données. Pour cela, comme pour un projet C#, il faut référencer la base dans le projet (References -> Clic-droit -> Database Reference). On peut faire référence à une autre base SQL, à un autre projet SQL Server Database ou encore à un .dacpac. Cette manipulation va créer une variable qui pourra être utilisée dans les scripts pour cibler cette autre base de données.

collaborateur chez C2S

Matthieu Anceret, Ingénieur d’Etudes

Vous avez trouvé cet article intéressant ? Partagez le sur vos réseaux sociaux !

Partager sur linkedin
LinkedIn
Partager sur twitter
Twitter
Siège C2S – Guyancourt Parc Ariane III, Rue Alfred Kastler,
78280 Guyancourt
E-mail: contact@c2s.fr
Téléphone: +33 1 30 60 82 00