Question Utilisez-vous le contrôle de source pour vos éléments de base de données? [fermé]


Je pense que mon magasin a un trou parce que nous n'avons pas un processus solide en place pour la version de nos changements de schéma de base de données. Nous faisons beaucoup de sauvegardes, donc nous sommes plus ou moins couverts, mais c'est une mauvaise habitude de compter sur votre dernière ligne de défense de cette façon.

Étonnamment, cela semble être un dénominateur commun. Beaucoup de magasins auxquels j'ai parlé ignorent ce problème parce que leurs bases de données ne changent pas souvent, et ils essayent simplement d'être méticuleux.

Cependant, je sais comment ça se passe. Ce n'est qu'une question de temps avant que les choses s'alignent et que quelque chose disparaisse.

Existe-t-il des meilleures pratiques pour cela? Quelles sont les stratégies qui ont fonctionné pour vous?


559


origine


Réponses:


Doit lire Obtenez votre base de données sous le contrôle de version. Vérifiez la série de messages par K. Scott Allen.

Quand il s'agit du contrôle de version, la base de données est souvent un deuxième ou même un citoyen de troisième classe. D'après ce que j'ai vu, les équipes qui ne penseraient jamais à écrire du code sans contrôle de version dans un million d'années - et à juste titre - peuvent être totalement inconscientes du besoin de contrôle de version autour des bases de données critiques sur lesquelles reposent leurs applications. Je ne sais pas comment vous pouvez vous appeler un ingénieur logiciel et maintenir un visage impassible lorsque votre base de données n'est pas exactement sous le même niveau rigoureux de contrôle de la source que le reste de votre code. Ne laissez pas cela vous arriver. Obtenez votre base de données sous le contrôle de version.


365



Les bases de données elles-mêmes? Non

Les scripts qui les créent, y compris les insertions de données statiques, les procédures stockées et similaires; bien sûr. Ce sont des fichiers texte, ils sont inclus dans le projet et sont archivés comme tout le reste.

Bien sûr, dans un monde idéal, votre outil de gestion de base de données le ferait; mais vous devez juste être discipliné à ce sujet.


129



J'adore les migrations de Rails ActiveRecord. Il extrait le script DML au format ruby ​​qui peut ensuite être facilement versionné dans votre référentiel source.

Cependant, avec un peu de travail, vous pourriez faire la même chose. Tous les changements DDL (ALTER TABLE, etc.) peuvent être stockés dans des fichiers texte. Conservez un système de numérotation (ou un horodatage) pour les noms de fichiers et appliquez-les en séquence.

Rails dispose également d'une table 'version' dans la base de données qui conserve la trace de la dernière migration appliquée. Vous pouvez faire la même chose facilement.


34



Check-out LiquiBase pour gérer les modifications de base de données à l'aide du contrôle de source.


32



Vous ne devriez jamais vous connecter et commencer à entrer des commandes "ALTER TABLE" pour changer une base de données de production. Le projet sur lequel je suis dispose d'une base de données sur chaque site client, de sorte que chaque modification de la base de données s'effectue à deux endroits: un fichier de vidage utilisé pour créer une nouvelle base de données sur un nouveau site client et un fichier de mise à jour à chaque mise à jour qui vérifie le numéro de version de votre base de données actuelle par rapport au numéro le plus élevé dans le fichier, et met à jour votre base de données en place. Ainsi, par exemple, les dernières mises à jour:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Je suis sûr qu'il y a une meilleure façon de le faire, mais ça a fonctionné pour moi jusqu'ici.


29



Oui. Le code est le code. Ma règle générale est que je dois être capable de construire et de déployer l'application à partir de zéro, sans regarder une machine de développement ou de production.


15



La meilleure pratique que j'ai vu est la création d'un script de génération pour scrapper et reconstruire votre base de données sur un serveur de transfert. Chaque itération a reçu un dossier pour les changements de base de données, tous les changements ont été scriptés avec "Drop ... Create". De cette façon, vous pouvez revenir à une version antérieure à tout moment en pointant la construction vers le dossier vers lequel vous voulez effectuer la version.

Je crois que cela a été fait avec NaNt / CruiseControl.


14



OUI, je pense qu'il est important de versionner votre base de données. Pas les données, mais le schéma pour certain.

Dans Ruby On Rails, ceci est géré par le framework avec "migrations". Chaque fois que vous modifiez la base de données, vous créez un script qui applique les modifications et le vérifie dans le contrôle de la source.

Mon magasin a tellement aimé cette idée que nous avons ajouté la fonctionnalité à notre build Java. en utilisant des scripts shell et Ant. Nous avons intégré le processus dans notre routine de déploiement. Il serait assez facile d'écrire des scripts pour faire la même chose dans d'autres frameworks qui ne supportent pas la gestion des versions de BD.


11



Les nouveaux projets de base de données dans Visual Studio fournissent le contrôle de source et les scripts de modification.

Ils ont un bon outil qui compare les bases de données et peut générer un script qui convertit le schéma de l'un dans l'autre, ou met à jour les données dans l'un pour correspondre à l'autre.

Le schéma db est "déchiqueté" pour créer beaucoup, beaucoup de petits fichiers .sql, un par commande DDL qui décrit la base de données.

+ tom


Infos supplémentaires 2008-11-30

Je l'utilise comme développeur depuis un an et je l'aime vraiment. Il est facile de comparer mon travail de développement à la production et de générer un script à utiliser pour la publication. Je ne sais pas s'il manque des fonctionnalités dont les administrateurs de base de données ont besoin pour les projets de type «entreprise».

Parce que le schéma est "déchiqueté" dans les fichiers SQL, le contrôle de la source fonctionne correctement.

Un gotcha est que vous devez avoir un état d'esprit différent lorsque vous utilisez un projet DB. L'outil a un "projet db" dans VS, qui est juste le sql, plus une base de données locale générée automatiquement qui a le schéma et d'autres données d'administration - mais aucune de vos données d'application, plus votre db dev local que vous utilisez pour travail de développement de données d'application. Vous êtes rarement au courant de la DB générée automatiquement, mais vous devez savoir qu'il est là pour que vous puissiez le laisser seul :). Ce db spécial est clairement reconnaissable parce qu'il a un Guid dans son nom,

Le projet VS DB fait un bon travail d'intégration des modifications de base de données que les autres membres de l'équipe ont apportées à votre projet local / db associé. mais vous devez prendre l'étape supplémentaire pour comparer le schéma de projet avec votre schéma dev db local et appliquer les mods. Cela a du sens, mais cela semble bizarre au début.

Les projets DB sont un outil très puissant. Ils génèrent non seulement des scripts mais peuvent les appliquer immédiatement. Assurez-vous de ne pas détruire votre production db avec elle. ;)

J'aime vraiment les projets VS DB et je pense utiliser cet outil pour tous mes projets db à venir.

+ tom


8



Demander aux équipes de développement d'utiliser un système de gestion de contrôle de source de base de données SQL n'est pas la solution miracle qui empêchera les problèmes de se produire. En soi, le contrôle de source de base de données introduit une surcharge supplémentaire car les développeurs doivent enregistrer les modifications apportées à un objet dans un script SQL distinct, ouvrir le client du système de contrôle source, archiver le fichier de script SQL à l'aide du client, puis appliquer les modifications à la base de données en direct.

Je peux suggérer d'utiliser le complément SSMS appelé Contrôle de source ApexSQL. Il permet aux développeurs de mapper facilement les objets de la base de données avec le système de contrôle de la source via l'assistant directement à partir de SSMS. Le complément inclut la prise en charge de TFS, Git, Subversion et d'autres systèmes SC. Il inclut également la prise en charge des données statiques contrôlant la source.

Après avoir téléchargé et installé ApexSQL Source Control, il vous suffit de cliquer avec le bouton droit sur la base de données que vous voulez contrôler et de naviguer vers le sous-menu Contrôle de la source ApexSQL dans SSMS. Cliquez sur l'option Lier la base de données à la commande de source, sélectionnez le système de contrôle de source et le modèle de développement. Après cela, vous devrez fournir les informations de connexion et la chaîne de référentiel pour le système de contrôle de la source que vous avez choisi.

Vous pouvez lire cet article pour plus d'informations: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/


8



Je le fais en sauvegardant des scripts de création / mise à jour et un script qui génère des sampledata.


6