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

Question

J'ai l'impression que ma boutique a un trou parce que nous n'avons pas un solide processus en place pour la gestion des versions de notre schéma de base de données change. Nous faisons beaucoup de sauvegardes de sorte que nous sommes plus ou moins couverts, mais c'est une mauvaise pratique de compter sur votre dernière ligne de défense de cette façon.

Étonnamment, ce qui semble être un dénominateur commun. De nombreux magasins, j'ai parlé d'ignorer cette question parce que leurs bases de données ne changent pas souvent, et ils fondamentalement juste essayer d'être méticuleux.

Cependant, je sais comment cette histoire va. C'est seulement une question de temps avant que les choses s'alignent tout simplement faux et quelque chose vient à manquer.

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

Answer 1

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

Quand il s'agit de contrôle de version, la base de données est souvent un deuxième ou même la troisième classe des citoyens. De ce que j'ai vu, les équipes qui ne pense jamais à écrire du code sans le contrôle de version dans un million d'années-et à juste titre-- peut en quelque sorte être complètement inconscient pour le besoin de contrôle de version autour de la critique des bases de données de leurs applications s'appuient sur. Je ne sais pas comment vous pouvez appeler vous-même un ingénieur en logiciel et de maintenir un visage impassible quand votre base de données n'est pas exactement dans les mêmes rigoureux au niveau du contrôle de code source que le reste de votre code. Ne laissez pas cela vous arriver. Obtenez votre base de données sous contrôle de version.

Answer 2

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.

Answer 3

J'adore les Rails ActiveRecord migrations. Elle résumés de la DML de script ruby qui peut ensuite être facilement version avait dans le référentiel source.

Cependant, avec un peu de travail, vous pourriez faire la même chose. Toutes les modifications de DDL (ALTER TABLE, etc.) peuvent être stockés dans des fichiers texte. Maintenir un système de numérotation (ou la date) pour les noms de fichiers, et de les appliquer dans l'ordre.

Rails a aussi une "version" de la table dans la base de données qui conserve la trace de la dernière demande de migration. Vous pouvez faire de même facilement.

Answer 4

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

Answer 5

Vous ne devriez jamais vous suffit de vous connecter et de commencer la saisie des "ALTER TABLE" commandes pour modifier une base de données de production. Le projet que je suis sur a base de données sur chaque site du client, et donc à chaque changement de la base de données est faite en deux endroits, un fichier de vidage qui est utilisé pour créer une nouvelle base de données sur un nouveau site du client, et un fichier de mise à jour qui est exécuté à chaque mise à jour qui vérifie votre base de données actuelle du numéro de version contre le plus grand nombre dans le fichier, et les mises à jour de votre base de données en place. Ainsi, par exemple, les deux 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 est une meilleure façon de le faire, mais cela a fonctionné pour moi jusqu'à présent.