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

Je pense que ma boutique a un trou parce que nous n'avons pas de processus solide en place pour versionner nos modifications 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 pratique de compter sur votre dernière ligne de défense de cette façon.

Étonnamment, cela semble être un fil conducteur. De nombreux magasins à qui j'ai parlé ignorent ce problème car leurs bases de données ne changent pas souvent, et ils essaient simplement d'être méticuleux.

Cependant, je sais comment se déroule cette histoire. Ce n'est qu'une question de temps avant que les choses ne s'alignent correctement et qu'il manque quelque chose.

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

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

En ce qui concerne le contrôle de version, la base de données est souvent un citoyen de deuxième ou même de troisième classe. D'après ce que j'ai vu, les équipes qui n'auraient jamais pensé à écrire du code sans contrôle de version dans un million d'années - et à juste titre - peuvent en quelque sorte être complètement inconscientes de la nécessité d'un contrôle de version autour des bases de données critiques sur lesquelles leurs applications s'appuient. Je ne sais pas comment vous pouvez vous appeler ingénieur logiciel et garder un visage droit lorsque votre base de données n'est pas exactement sous le même niveau rigoureux de contrôle de source que le reste de votre code. Ne laissez pas cela vous arriver. Obtenez votre base de données sous contrôle de version.

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 et extraits comme tout le reste.

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

J'adore les migrations Rails ActiveRecord. Il résume le script DML en 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. Toutes les modifications DDL (ALTER TABLE, etc.) peuvent être stockées 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 possède également une table de «version» dans la base de données qui conserve la trace de la dernière migration appliquée. Vous pouvez faire de même facilement.

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

Vous ne devez jamais simplement vous connecter et commencer à entrer les commandes "ALTER TABLE" pour changer une base de données de production. Le projet sur lequel je suis a une base de données sur chaque site client, et donc chaque modification de la base de données est effectuée à deux endroits, un fichier de vidage qui est utilisé pour créer une nouvelle base de données sur un nouveau site client et un fichier de mise à jour qui est exécuté à 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é du fichier et met à jour 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 existe une meilleure façon de procéder, mais cela a fonctionné pour moi jusqu'à présent.

Oui. Le code est le code. Ma règle d'or est que je dois pouvoir créer et déployer l'application à partir de zéro , sans regarder une machine de développement ou de production.

La meilleure pratique que j'ai vue consiste à créer un script de génération pour supprimer et reconstruire votre base de données sur un serveur intermédiaire. Chaque itération a reçu un dossier pour les modifications de la base de données, toutes les modifications ont été scriptées avec "Drop ... Create". De cette façon, vous pouvez revenir à une version antérieure à tout moment en pointant la génération vers le dossier vers lequel vous souhaitez effectuer la version.

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

OUI, je pense qu'il est important de mettre à jour votre base de données. Pas les données, mais le schéma à coup sûr.

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

Ma boutique a tellement aimé cette idée que nous avons ajouté la fonctionnalité à notre build basé sur 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 prennent pas en charge la version DB.

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

Ils ont un bel 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'une pour correspondre à l'autre.

Le schéma db est "déchiqueté" pour créer de très nombreux 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 j'aime vraiment ça. Cela permet de comparer facilement mon travail de développement à la production et de générer un script à utiliser pour la version. 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".

Étant donné que le schéma est "déchiqueté" dans des fichiers SQL, le contrôle de code source fonctionne correctement.

Un problème 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 quelques autres données d'administration - mais aucune de vos données d'application, plus votre db de développement local que vous utilisez pour travail de développement de données d'application. Vous êtes rarement au courant de la base de données générée automatiquement, mais vous devez la connaître pour pouvoir la laisser seule :). Ce db spécial est clairement reconnaissable car 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 d'autres membres de l'équipe ont apportées à votre projet local / base de données associée. mais vous devez prendre l'étape supplémentaire pour comparer le schéma du projet avec votre schéma de développement local et appliquer les mods. Cela a du sens, mais cela semble gênant au début.

Les projets DB sont un outil très puissant. Non seulement ils génèrent des scripts, mais ils peuvent les appliquer immédiatement. Assurez-vous de ne pas détruire votre base de données de production avec. ;)

J'aime vraiment les projets VS DB et je compte utiliser cet outil pour tous mes projets db à l'avenir.

+ tom

Obliger les équipes de développement à utiliser un système de gestion du contrôle des sources de base de données SQL n'est pas la solution miracle qui empêchera les problèmes de se produire. À lui seul, le contrôle de code source de la base de données introduit des frais supplémentaires car les développeurs doivent enregistrer les modifications qu'ils ont apportées à un objet dans un script SQL distinct, ouvrir le client du système de contrôle de code 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é ApexSQL Source Control . Il permet aux développeurs de mapper facilement des objets de base de données avec le système de contrôle de source via l'assistant directement depuis SSMS. Le complément comprend la prise en charge de TFS, Git, Subversion et d'autres systèmes SC. Il inclut également la prise en charge du contrôle de source des données statiques.

Après avoir téléchargé et installé ApexSQL Source Control, cliquez simplement avec le bouton droit sur la base de données que vous souhaitez contrôler de version et accédez au sous-menu ApexSQL Source Control dans SSMS. Cliquez sur l'option Lier la base de données au contrôle 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 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/

Je le fais en enregistrant des scripts de création / mise à jour et un script qui génère des échantillons de données.

Oui, nous le faisons en conservant notre SQL dans le cadre de notre build - nous conservons DROP.sql, CREATE.sql, USERS.sql, VALUES.sql et le contrôle de version pour que nous puissions revenir à n'importe quelle version balisée.

Nous avons également des tâches de fourmi qui peuvent recréer la base de données à tout moment.

De plus, le SQL est ensuite balisé avec votre code source qui l'accompagne.

Le schéma le plus réussi que j'ai jamais utilisé sur un projet a combiné des sauvegardes et des fichiers SQL différentiels. Fondamentalement, nous prendrions une sauvegarde de notre base de données après chaque version et ferions un vidage SQL afin de pouvoir créer un schéma vierge à partir de zéro si nous en avions également besoin. Ensuite, chaque fois que vous deviez apporter une modification à la base de données, vous ajoutiez un script de remplacement au répertoire sql sous contrôle de version. Nous préfixerions toujours un numéro de séquence ou une date au nom du fichier afin que le premier changement soit quelque chose comme 01_add_created_on_column.sql, et le script suivant soit 02_added_customers_index. Notre machine CI les vérifierait et les exécuterait séquentiellement sur une nouvelle copie de la base de données qui avait été restaurée à partir de la sauvegarde.

Nous avions également mis en place des scripts que les développeurs pouvaient utiliser pour réinitialiser leur base de données locale à la version actuelle avec une seule commande.

Nous contrôlons à la source tous nos objets créés dans la base de données. Et juste pour garder les développeurs honnêtes (parce que vous pouvez créer des objets sans qu'ils soient dans le contrôle de source), nos dbas recherchent périodiquement tout ce qui n'est pas dans le contrôle de source et s'ils trouvent quelque chose, ils le suppriment sans demander si c'est ok.

J'utilise SchemaBank pour contrôler la version de toutes mes modifications de schéma de base de données:

• à partir du jour 1, j'y importe mon vidage de schéma db
• j'ai commencé à changer la conception de mon schéma à l'aide d'un navigateur Web (car ils sont basés sur le SaaS / cloud)
• quand je veux mettre à jour mon serveur db, j'en génère le script change (SQL) et l'applique à la db. Dans Schemabank, ils me mandatent pour valider mon travail en tant que version avant de pouvoir générer un script de mise à jour. J'aime ce genre de pratique pour pouvoir toujours remonter quand j'en ai besoin.

Notre règle d'équipe est de ne JAMAIS toucher directement le serveur de base de données sans avoir d'abord stocké le travail de conception. Mais cela arrive, quelqu'un pourrait être tenté de violer la règle, par souci de commodité. Nous importons à nouveau le vidage de schéma dans la banque de schémas et le laissons faire la différence et bash quelqu'un en cas de divergence. Bien que nous puissions en générer les scripts de modification pour synchroniser notre conception de base de données et de schéma, nous détestons cela.

Soit dit en passant, ils nous ont également permis de créer des branches dans l'arborescence de contrôle de version afin que je puisse en conserver une pour la préparation et une pour la production. Et un pour le codage du bac à sable.

Un outil de conception de schéma basé sur le Web assez soigné avec contrôle de version et gestion des modifications.

J'ai tout le nécessaire pour recréer ma base de données à partir du métal nu, moins les données elles-mêmes. Je suis sûr qu'il existe de nombreuses façons de le faire, mais tous mes scripts et autres sont stockés dans subversion et nous pouvons reconstruire la structure de base de données et autres en retirant tout cela de subversion et en exécutant un programme d'installation.

Je crée généralement un script SQL pour chaque modification que j'apporte, et un autre pour annuler ces modifications et garder ces scripts sous contrôle de version.

Ensuite, nous avons un moyen de créer une nouvelle base de données à jour sur demande, et pouvons facilement passer d'une révision à l'autre. Chaque fois que nous faisons une version, nous regroupons les scripts (prend un peu de travail manuel, mais c'est rarement difficile ), nous avons donc également un ensemble de scripts qui peuvent convertir entre les versions.

Oui, avant de le dire, c'est très similaire à ce que font Rails et d'autres, mais cela semble fonctionner assez bien, donc je n'ai aucun problème à admettre que j'ai sans vergogne soulevé l'idée :)

J'utilise des scripts SQL CREATE exportés de MySQL Workbech, puis en utilisant la fonctionnalité "Export SQL ALTER", je me retrouve avec une série de scripts de création (numérotés bien sûr) et les scripts de modification qui peuvent appliquer les changements entre eux.

3.- Exporter le script SQL ALTER Normalement, vous devez maintenant écrire les instructions ALTER TABLE à la main, reflétant les modifications que vous avez apportées au modèle. Mais vous pouvez être intelligent et laisser Workbench faire le travail dur pour vous. Sélectionnez simplement Fichier -> Exporter -> Script SQL ALTER de Forward Engineer… dans le menu principal.

Cela vous demandera de spécifier le fichier SQL CREATE auquel le modèle actuel doit être comparé.

Sélectionnez le script SQL CREATE à l'étape 1. L'outil générera alors le script ALTER TABLE pour vous et vous pourrez exécuter ce script sur votre base de données pour le mettre à jour.

Vous pouvez le faire en utilisant le navigateur de requêtes MySQL ou le client mysql. Votre modèle et votre base de données sont maintenant synchronisés!

Source: MySQL Workbench Community Edition: Guide de synchronisation des schémas

Tous ces scripts sont bien sûr à l'intérieur sous contrôle de version.

Oui toujours. Vous devriez être en mesure de recréer votre structure de base de données de production avec un ensemble utile d'exemples de données chaque fois que nécessaire. Si vous ne le faites pas, au fil du temps, des changements mineurs pour faire fonctionner les choses sont oubliés, puis un jour, vous serez mordu, gros temps. C'est une assurance dont vous ne pensez peut-être pas avoir besoin, mais le jour où vous le faites, cela en vaut le prix 10 fois plus!

Il y a eu beaucoup de discussions sur le modèle de base de données lui-même, mais nous conservons également les données requises dans des fichiers .SQL.

Par exemple, pour être utile, votre application pourrait en avoir besoin lors de l'installation:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Nous aurions un fichier appelé currency.sqlsous subversion. En tant qu'étape manuelle dans le processus de construction, nous comparons le précédent currency.sql au dernier et écrivons un script de mise à niveau.

Nous contrôlons la version et la source de tout ce qui entoure nos bases de données:

• DDL (créer et modifier)
• DML (données de référence, codes, etc.)
• Modifications du modèle de données (en utilisant ERwin ou ER / Studio)
• Modifications de la configuration de la base de données (autorisations, objets de sécurité, modifications générales de configuration)

Nous faisons tout cela avec des tâches automatisées à l'aide de Change Manager et de certains scripts personnalisés. Nous avons Change Manager qui surveille ces changements et notifie quand ils sont effectués.

Je crois que chaque base de données devrait être sous contrôle de source et les développeurs devraient avoir un moyen facile de créer leur base de données locale à partir de zéro. Inspiré par Visual Studio pour les professionnels de la base de données, j'ai créé un outil open source qui écrit des scripts pour les bases de données MS SQL et fournit et un moyen simple de les déployer sur votre moteur de base de données local. Essayez http://dbsourcetools.codeplex.com/ . Amusez-vous, - Nathan.

Si votre base de données est SQL Server, nous avons peut-être la solution que vous recherchez. SQL Source Control 1.0 est maintenant disponible.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Cela s'intègre dans SSMS et fournit la colle entre vos objets de base de données et votre VCS. Le `` scripting out '' se déroule de manière transparente (il utilise le moteur de comparaison SQL sous le capot), ce qui devrait le rendre si simple à utiliser que les développeurs ne seront pas découragés d'adopter le processus.

Une solution alternative de Visual Studio est ReadyRoll , qui est implémentée en tant que sous-type du projet de base de données SSDT. Cela prend une approche axée sur les migrations, qui est plus adaptée aux besoins d'automatisation des équipes DevOps.

Je contrôle à la source le schéma de la base de données en scénarisant tous les objets (définitions de table, index, procédures stockées, etc.). Mais, comme pour les données elles-mêmes, reposez-vous simplement sur des sauvegardes régulières. Cela garantit que tous les changements structurels sont capturés avec un historique de révision approprié, mais n'alourdit pas la base de données chaque fois que les données changent.

Dans notre entreprise, nous utilisons des scripts de changement de base de données. Lorsqu'un script est exécuté, son nom est stocké dans la base de données et ne s'exécutera plus, sauf si cette ligne est supprimée. Les scripts sont nommés en fonction de la date, de l'heure et de la branche du code, de sorte qu'une exécution contrôlée est possible.

Beaucoup de tests sont effectués avant que les scripts ne soient exécutés dans l'environnement réel, donc les "oopsies" ne se produisent, en général, que sur les bases de données de développement.

Nous sommes en train de déplacer toutes les bases de données vers le contrôle de code source. Nous utilisons sqlcompare pour créer un script pour la base de données (une fonction d'édition professionnelle, malheureusement) et pour mettre ce résultat dans SVN.

Le succès de votre mise en œuvre dépendra beaucoup de la culture et des pratiques de votre organisation. Les gens ici croient en la création d'une base de données par application. Il existe un ensemble commun de bases de données qui sont également utilisées par la plupart des applications, ce qui entraîne de nombreuses dépendances entre bases de données (certaines d'entre elles sont circulaires). Il a été notoirement difficile de placer les schémas de base de données dans le contrôle de code source en raison des dépendances entre bases de données de nos systèmes.

Bonne chance à vous, plus tôt vous l'essayez, plus tôt vous aurez réglé vos problèmes.

J'ai utilisé l'outil dbdeploy de ThoughtWorks sur http://dbdeploy.com/ . Il encourage l'utilisation de scripts de migration. Chaque version, nous avons consolidé les scripts de changement dans un seul fichier pour faciliter la compréhension et permettre aux administrateurs de base de données de «bénir» les changements.

Cela a toujours été une grande gêne pour moi aussi - il semble qu'il soit tout simplement trop facile d'apporter une modification rapide à votre base de données de développement, de l'enregistrer (en oubliant d'enregistrer un script de changement), puis vous êtes coincé. Vous pouvez annuler ce que vous venez de faire et le refaire pour créer le script de changement, ou l'écrire à partir de zéro si vous le souhaitez bien sûr aussi, même si cela prend beaucoup de temps à écrire des scripts.

Un outil que j'ai utilisé dans le passé qui a aidé à cela est SQL Delta. Il vous montrera les différences entre deux bases de données (SQL server / Oracle je crois) et générera tous les scripts de changement nécessaires pour migrer A-> B. Une autre bonne chose qu'il fait est de montrer toutes les différences entre le contenu de la base de données entre la base de données de production (ou de test) et votre base de développement. Étant donné que de plus en plus d'applications stockent la configuration et l'état qui sont essentiels à leur exécution dans les tables de base de données, il peut être très difficile d'avoir des scripts de modification qui suppriment, ajoutent et modifient les lignes appropriées. SQL Delta affiche les lignes de la base de données exactement comme elles auraient l'air dans un outil Diff - modifiées, ajoutées, supprimées.

Un excellent outil. Voici le lien: http://www.sqldelta.com/

RedGate est génial, nous générons de nouveaux instantanés lorsque des modifications de base de données sont effectuées (un petit fichier binaire) et conservons ce fichier dans les projets en tant que ressource. Chaque fois que nous devons mettre à jour la base de données, nous utilisons la boîte à outils de RedGate pour mettre à jour la base de données, ainsi que la possibilité de créer de nouvelles bases de données à partir de vides.

RedGate crée également des instantanés de données, même si je n'ai pas personnellement travaillé avec eux, ils sont tout aussi robustes.

Pour info Ceci a également été évoqué il y a quelques jours par Dana ... Procédures stockées / schéma DB dans le contrôle de code source