Verwenden Sie die Versionskontrolle für Ihre Datenbankelemente?

Question

Ich habe das Gefühl, dass mein Geschäft eine Lücke hat, weil wir keinen soliden Prozess für die Versionierung unserer Datenbankschemaänderungen haben. Wir machen viele Backups, so dass wir mehr oder weniger abgesichert sind, aber es ist eine schlechte Praxis, sich auf diese Weise auf die letzte Verteidigungslinie zu verlassen.

Überraschenderweise scheint dies ein roter Faden zu sein. Viele Geschäfte, mit denen ich gesprochen habe, ignorieren dieses Problem, weil sich ihre Datenbanken nicht oft ändern und sie im Grunde nur versuchen, peinlich genau zu sein.

Aber ich weiß, wie die Geschichte ausgeht. Es ist nur eine Frage der Zeit, bis sich die Dinge einfach falsch anordnen und etwas verloren geht.

Gibt es hierfür bewährte Verfahren? Welche Strategien haben sich für Sie bewährt?

Answer 1

Unbedingt lesen Datenbank unter Versionskontrolle stellen . Lesen Sie die Serie von Beiträgen von K. Scott Allen.

Wenn es um Versionskontrolle geht, ist die Datenbank oft ein Bürger zweiter oder sogar dritter Klasse. Ich habe gesehen, dass Teams, die niemals auf die Idee kämen, Code ohne Versionskontrolle zu schreiben - und das zu Recht -, die Notwendigkeit einer Versionskontrolle für die kritischen Datenbanken, auf die sich ihre Anwendungen stützen, völlig außer Acht lassen können. Ich weiß nicht, wie Sie sich selbst als Softwareentwickler bezeichnen und ein ernstes Gesicht machen können, wenn Ihre Datenbank nicht genau dem gleichen strengen Niveau der Versionskontrolle unterliegt wie der Rest Ihres Codes. Lassen Sie das nicht mit sich machen. Bringen Sie Ihre Datenbank unter Versionskontrolle.

Answer 2

Die Datenbanken selbst? Nein

Die Skripte, mit denen sie erstellt werden, einschließlich der Einfügung statischer Daten, gespeicherter Prozeduren und dergleichen, natürlich. Es handelt sich um Textdateien, die in das Projekt aufgenommen werden und wie alles andere ein- und ausgecheckt werden.

In einer idealen Welt würde Ihr Datenbankverwaltungsprogramm dies natürlich tun, aber Sie müssen dabei diszipliniert vorgehen.

Answer 3

Ich liebe Rails ActiveRecord Migrationen absolut. Es abstrahiert die DML zu Ruby-Skript, das dann leicht in Ihrem Source-Repository versioniert werden kann.

Mit ein wenig Arbeit können Sie jedoch das Gleiche tun. Alle DDL-Änderungen (ALTER TABLE, usw.) können in Textdateien gespeichert werden. Behalten Sie ein Nummerierungssystem (oder einen Datumsstempel) für die Dateinamen bei und wenden Sie sie nacheinander an.

Rails hat auch eine 'Version' Tabelle in der DB, die die letzte angewandte Migration aufzeichnet. Sie können das Gleiche einfach tun.

Answer 4

Überprüfen Sie LiquiBase für die Verwaltung von Datenbankänderungen unter Verwendung der Versionskontrolle.

Answer 5

Sie sollten sich niemals einfach einloggen und "ALTER TABLE"-Befehle eingeben, um eine Produktionsdatenbank zu ändern. Das Projekt, an dem ich arbeite, hat eine Datenbank für jeden Kundenstandort, und so wird jede Änderung an der Datenbank an zwei Stellen vorgenommen: in einer Dump-Datei, mit der eine neue Datenbank für einen neuen Kundenstandort erstellt wird, und in einer Update-Datei, die bei jeder Aktualisierung ausgeführt wird und die die aktuelle Versionsnummer der Datenbank mit der höchsten Nummer in der Datei vergleicht und die Datenbank an Ort und Stelle aktualisiert. Zum Beispiel die letzten paar Aktualisierungen:

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

Ich bin sicher, dass es einen besseren Weg gibt, dies zu tun, aber bisher hat es für mich funktioniert.