Je souhaite conserver le schéma et les données «statiques» d'une base de données SQL Server sous forme de code dans un système de contrôle de version. J'aimerais également pouvoir déployer des versions spécifiques du code de la base de données sur des instances réelles de la base de données pertinente, c'est-à-dire migrer une base de données vers une nouvelle version (et éventuellement «migrer vers le bas» vers une ancienne version).

Clarification

Bases de données

Je suppose que je n'ai pas besoin d'expliquer ce qu'est une base de données ou ce SQL Server est un système de base de données spécifique, c'est-à-dire un logiciel spécifique de gestion de bases de données.

Schéma de base de données en tant que code

Parmi les développeurs de logiciels qui travaillent avec des bases de données, il est souhaitable pour pouvoir maintenir le " schéma" d'une base de données, c'est-à-dire des informations sur sa structure, sous forme de " code". Ce code devrait permettre à quelqu'un de créer une base de données avec le même «schéma» que celui représenté par le code. Le code peut être sous la forme d'instructions DDL ( Data Definition Language), par exemple Code SQL, généralement dans une version spécifique du fournisseur, utilisé pour créer des objets tels que des tables et des index dans une base de données, ou il pourrait être dans un langage de programmation général, par exemple Java, Ruby, C #, etc.

Contrôle de version et code

Une fois le schéma d'une base de données est représentée dans le code, ce code peut être maintenu dans un contrôle de version ou un système de contrôle de source, logiciel de gestion de contrôle de révision. De Wikipedia:

Le contrôle de révision, également connu sous le nom de contrôle de version et de contrôle de source (et un aspect de la gestion de la configuration logicielle), consiste à gérer les modifications apportées aux documents, aux programmes informatiques, aux grands sites Web et d'autres collections d'informations.

La gestion du code qui représente le schéma d'une base de données dans un système de contrôle de version est souhaitable car un historique des modifications du schéma peut être conservé et d'autres outils, comme l'ensemble d'outils que je pose dans cette question, peuvent accéder le schéma, même les différentes versions du schéma, pour d'autres utilisations.

Déploiement de logiciel

' Déploiement', dans le contexte du développement de logiciel et la maintenance du logiciel, implique "... toutes les activités qui rendent un système logiciel disponible pour utilisation". Dans le cadre de cette question, je suis intéressé par les recommandations d'outils logiciels permettant de mettre à disposition une version spécifique d'un schéma de base de données sous la forme d'instances concrètes spécifiques de bases de données dans le SGBD SQL Server.

Exemple

À titre d'exemple, considérons un schéma de base de données avec les versions v1 , v2 et v3 , et un certain nombre de bases de données réelles , qui ont tous une de ces versions du schéma. Pour cette question, le logiciel recommandé doit être capable de mettre à niveau (ou de rétrograder) une base de données particulière de sa version actuelle vers toute autre version du même schéma, et il doit utiliser le code de la version de schéma spécifique qui est stockée dans le système de contrôle de version.

Quelques critères spécifiques mentionnés dans les commentaires

"sélectionnez une entrée de contrôle de version contenant un schéma, (re) notez la base de données pour qu'elle corresponde (qu'est-ce que cela signifie exactement?"

Le schéma de la base de données est représenté sous forme de code dans un système de contrôle de version. Je ne suis pas intéressé par les outils qui fonctionnent directement avec le contrôle de version. Les outils pour lesquels cette question sollicite des recommandations devraient pouvoir utiliser une 'version' du schéma de base de données. Un exemple de schéma 'version' serait le code qui représente le schéma comme une révision spécifique ('commit' dans Git) ou une balise / étiquette spécifique pour le contrôle de version systèmes qui prennent en charge de telles fonctionnalités.

Voici une liste de base des fonctionnalités qui devraient être fournies pour un outil permettant de "(re) noter la base de données [cible] pour qu'elle corresponde":

Tables

• Si une table existe dans le schéma source mais pas dans la base de données cible, l'outil doit créer la table dans la base de données cible. Cela doit inclure des objets auxiliaires tels que des clés, des contraintes, des valeurs par défaut, des index, des déclencheurs, etc.
• Si une table n'existe pas dans le schéma source mais existe dans la base de données cible, l'outil doit fournir des moyens pour spécifier si la table de la base de données cible doit être supprimée ou non. [Ce paramètre peut s'appliquer à toutes ces tables.]

Colonnes de table

• Si une colonne existe dans une table du schéma source mais pas dans le même ¹ table dans la base de données cible, elle doit être créée dans la base de données cible. Comme les instructions DDL pour la plupart des (?) SGBD fournissent déjà des moyens de spécifier la valeur initiale des nouvelles colonnes pour les tables existantes (par exemple, en particulier pour les nouvelles colonnes qui n'autorisent pas les valeurs NULL ), Je ne sais pas si quelque chose de spécial doit être fourni par l'outil lui-même pour gérer cela. Cependant , si un outil recommandé utilise une forme de «code de schéma» qui n'est pas les instructions DDL standard du SGBD respectif ² , alors l'outil doit fournir un moyen de spécifier les valeurs initiales des colonnes à ajouter.
• Si une colonne de table n'existe pas dans le schéma source mais existe dans la base de données cible, le L'outil doit fournir des moyens pour spécifier si la colonne de la base de données cible doit être supprimée ou non. [Ce paramètre peut s'appliquer à toutes ces colonnes de tableau.]
• Si la même colonne de table ¹ existe à la fois dans le schéma source et dans les bases de données cible, mais qu'elles sont de types différents ou s'il existe d'autres différences (par exemple, longueur, échelle numérique, etc.), L'outil doit changer la colonne de la base de données cible pour qu'elle corresponde au schéma source et faire de son mieux pour conserver les données existantes dans cette colonne . Il est parfaitement valable pour un outil recommandé de quitter l'échec de rapport s'il ne parvient pas à convertir les données existantes sans perte (par exemple, si la longueur d'une colonne est diminuée et que les données doivent être tronquées).

Objets annexes à une ou plusieurs tables

Certains exemples de ces objets incluent des clés primaires, des contraintes de clé étrangère, des valeurs par défaut et des index.

• Si un objet accessoire à une table existe dans le schéma source mais pas dans la base de données cible, elle doit être créée dans la base de données cible. Comme ci-dessus, pour la création de nouvelles colonnes de table, l'outil doit être capable de gérer des scénarios impliquant d'éventuels conflits ou erreurs d'ajout de l'objet auxiliaire. Il est parfaitement normal que l'outil laisse simplement le soin aux personnes qui gèrent le code de schéma de s'assurer que tous les conflits ou erreurs sont traités correctement - il est tout à fait valable pour l'outil de quitter le rapport d'échec s'il rencontre un conflit ou une erreur comme celui-ci.
• Si un objet accessoire à une table n'existe pas dans le schéma source mais existe dans la base de données cible, l'outil doit fournir des moyens pour spécifier si l'objet auxiliaire doit être déposé dans la base de données cible. [Ce paramètre peut s'appliquer à tous ces objets.]
• Si le même objet ¹ existe à la fois dans le schéma source et dans la base de données cible, l'outil doit changer (ou supprimer et recrée) l'objet dans la base de données cible pour correspondre au schéma source.

Autres objets

Par «autre objet», je fais référence à des objets tels que des vues, des procédures stockées, des fonctions définies par l'utilisateur, etc. Ces objets peuvent généralement (?) être en toute sécurité supprimés et recréés. Un outil recommandé doit être capable de déposer et de recréer ces objets dans l'ordre nécessaire pour les objets qui dépendent d'autres objets de ce type (par exemple, une vue faisant référence à une autre vue).

• Si un autre objet, etc., existe dans le schéma source mais pas dans la base de données cible, il doit être créé dans la base de données cible.
• Si un autre objet comme une vue, bla bla bla, pas existe dans le schéma source mais existe dans la base de données cible, l'outil devrait fournir un moyen de spécifier si l'autre objet de la base de données cible doit être supprimé. [Ce paramètre peut s'appliquer à tous ces autres objets.]
• Si l'un de ces objets existe à la fois dans le schéma source et dans la base de données cible, l'outil doit modifier (ou supprimer et recréer) l'objet dans le base de données cible pour correspondre au schéma source.

Données statiques

Les lignes de la table avec des données «statiques» à synchroniser doivent être identifiées par les valeurs des colonnes du clé primaire pour cette table.

Les lignes des tables de données statiques de la base de données cible doivent être modifiées pour correspondre au schéma source. Les lignes du schéma source qui ne figurent pas dans la table cible doivent être insérées dans la table cible. Ce serait bien si l'outil fournissait un moyen de spécifier si les lignes qui existent dans la table cible et qui n'existent pas dans le schéma source doivent être supprimées.

Notes

¹ C'est en fait un point potentiellement subtil! La plupart des outils implémenteront probablement la «similitude» pour les objets de base de données comme ayant le même nom . Mais il existe des alternatives, au moins pour certains SGBD, par exemple dans SQL Server, les propriétés étendues peuvent être utilisées pour implémenter une forme d'identité persistante pour les objets de base de données qui est indépendante du nom de l'objet. Ce serait pratique car alors l'outil serait capable de gérer automatiquement (au moins certains) cas où les objets sont renommés.

² J'ai posé des questions sur SQL Server spécifiquement, mais à ceci point J'adorerais vraiment que quelqu'un fournisse une réponse à cette question, quel que soit le SGBD.