Datenbank-deployment best practices

Meist ändern wir bestehende Datenbank-Tabellen, gespeicherte Prozeduren, Funktionen oder Parameter in den Tabellen für software-upgrades/bugfixes. Und wenn es Zeit zum bereitstellen, unsere änderungen zu einer anderen Umgebung, wie die Produktion oder die preproduction, einige Teile unserer db-änderungen sind vergessen.

In unserem Unternehmen, einige Entwickler verwenden Sie ein Datenbank-Unterschied-Analyse-Anwendung, um herauszufinden, die Unterschiede zwischen test-und Produktionsumgebung.
Einige Entwickler store t-sql von jeder änderung, die Sie auf der db, so wie ich.

Ich Frage mich, was werden Sie tun, um die Bereitstellung db-änderungen der Produktionsumgebung. Warum Ihr so ? Oder was muss getan werden ?

Danke für die Antworten !

InformationsquelleAutor Canavar | 2009-02-02
  1. 9

    Wir haben unsere db unter Kontrolle der Quellcodeverwaltung. Änderungen werden nachverfolgt, so. Alles andere wäre ein Alptraum.

    Jeff hat einen Artikel über Sie zu http://blog.codinghorror.com/get-your-database-under-version-control/

    SQL Server hat die Generieren und Veröffentlichen von Skripts Assistenten, die können sehr hilfreich sein, wenn Sie wollen, um eine vorhandene Datenbank in die Quellcodeverwaltung ein.

    • Wie kann man eine DB unter SC?
    • Wenn Sie einen Blick auf die Assistenten-ich erwähnte es erstellt ein Skript, mit allem, was in es, einschließlich der Daten. Enthält SP ' s, aber wir haben getrennte Dateien für diejenigen, die zu machen es mehr überschaubar. Wir verwenden TortoiseSVN kontrollieren Sie diese Dateien. Wenn Sie sich bei Jeff ' s Artikel gibt es bessere Wege...
    • Ich würde upvote Sie ein paar mal, wenn ich könnte, erstaunt mich, wie viele Menschen nicht behandeln, SQL-änderungen wie jeder andere code.
    InformationsquelleAutor Joe Ratzer
  2. 5

    Jedes Datenbank-Objekt ist gespeichert in einer separaten Datei im version control system. Version control system Dateien enthalten, die wie in diesem Beispiel:

    |- tables
     |- employees.sql
     |- contracts.sql
|- packages
     |- contract_api.sql
|- functions
     |- get_employee_name.sql
...etc...

    Wann immer Sie Sie ändern einige DB-Objekte, dann müssen Sie auch ändern Sie die entsprechenden SQL (DDL) Datei im version-control-system. Zum Beispiel, wenn Sie ändern Paket contract_api, dann aktualisieren Sie die Datei contract_api.sql. Wie diese Datei wurde geändert - es kann installiert werden, sagen, durch einen continuous integration-engine.

    ABER, wie Sie wissen, gibt es DDL-Skripts können nicht ausgeführt werden zweimal. Zum Beispiel " CREATE TABLE mytable...' - Skript nur einmal ausgeführt werden. Und wenn Sie Ihr system bereits in Produktion ist, dann können Sie sich nicht leisten 'DROP TABLE mytable' - Anweisung in den header Ihrer "CREATE TABLE..." - Skript. Daher für Produktionssysteme, müssen Sie erstellen Sie so genannte delta scripts, die liefern nur die änderungen. In diesem Fall können Sie einfach erstellen Sie eine neue Datei namens employees_upd01.sql enthält statement 'ALTER TABLE mytable HINZUFÜGEN SPALTE...'.

    Nach einiger Zeit Ihr repository könnte wie folgt Aussehen:

    |- tables
     |- employees.sql
     |- employees_upgr20091001.sql
     |- employees_upgr20091004.sql
     |- contracts.sql
|- packages
     |- contract_api.sql
|- functions
     |- get_employee_name.sql
...etc...

    Und das ist OK, weil:
    1) wenn Sie benötigen, zu liefern der heutigen inkrementelle änderungen an den Datenbank - Bereitstellung von Dateien, die modifiziert wurden heute
    2) wenn Sie brauchen, um die Bereitstellung einer sauberen installation von Ihrem system - Sie führen alle Skripte in Reihenfolge, z.B. erste Mitarbeiter.sql, dann employees_upgr20091001.sql, etc.

    Als jedes DB-Objekt ist in einer separaten Datei im version-control-system, Sie haben eine gute Kontrolle über alle änderungen.

    InformationsquelleAutor
  3. 2

    In einem Projekt habe ich alle meine DB-änderungen, die in DDL-Skripts. Diese Skripte enthalten die SQL-Anweisungen, die notwendig sind, um ein upgrade der DB auf eine bestimmte version.
    Der Dateiname der script enthält auch die version-Nummer der DB, die die DB aktualisiert werden (_versionnumber.sql)

    Daneben, ich habe eine kleine Anwendung, die upgrades der DB auf die neueste version, indem Sie diese Skript-Dateien in der richtigen Reihenfolge (von aktuelle versionnr der DB, die im letzten Skript-Datei).

    Für neue Projekte, die ich jetzt verwenden Migrator.NET. In diesem Rahmen können Sie schreiben Sie Ihre DB-änderungen in C# - Klassen. Der Rahmen hat eine Konsole-Anwendung, mit der Sie ausgeführt werden können die DB-änderungen, und es ist auch möglich, verwenden Sie es mit msbuild.

    InformationsquelleAutor Frederik Gheysels
  4. 1

    Scripting und speichern jede änderung, die Sie gemacht in SQL ist der beste Weg, IMO.

    InformationsquelleAutor Galwegian
Schreibe einen Kommentar