Ich habe viel über dieses Thema nachgedacht und gelesen. Dies ist ein breites Thema der Konfigurationssteuerung und der Änderungsmanagementstrategie. CMMI hat eine Domäne in diesem Thema. Sogar in Unternehmen, die eine CMMI 3-5-Akkreditierung haben, werden ihre Datenbanken manchmal nicht versionskontrolliert.
Diese Frage soll beantwortet werden , während unter Berücksichtigung folgende Einschränkungen .
- Sie haben einen Keeper und jede DDL wird von diesem Keeper ausgeführt.
- Andere Personen können DDL-Anweisungen ausführen.
- Sie müssen nur protokollieren, welche Änderungen vorgenommen wurden, aber Sie müssen keine großen Unterschiede vergleichen.
- Ihr Datenbankentwurf erfolgt über ein externes Tool, das dann in der Datenbank veröffentlicht wird. Dieses externe Tool kann sogar DDL-Skripte in der Quellcodeverwaltung sein. Entscheidend ist jedoch, dass Sie die Quellcodeverwaltung durchführen und diese dann in der Datenbank veröffentlichen.
- Sie müssen nicht sofort Änderungen kennen, sondern von Zeit zu Zeit: dh stündlich, täglich.
- Sie haben eine definierte Serverstruktur: Entwicklung, Test, Produktion. Und eine gute Teststrategie.
Antwort 1
- Wenn 1, 4, 6 wahr ist, können Sie eine externe Quellcodeverwaltung verwenden. Beispielsweise
- Embercadero verfügt über ein Tool zur Verwaltung von Datenbankänderungen ( http://www.embarcadero.com/products/db-change-manager-xe ). Welche hat die Fähigkeit, eine Datenbank (Oracle) zurückzuentwickeln und in ihre Quellcodeverwaltung zu setzen. Dann kann eine beliebige Anzahl von Entwicklern, dba, dieses Schema erreichen und Änderungen daran vornehmen.
- Oracle SQL Designer ähnelt diesem Ansatz.
- Indem Sie Tabellenskripte für die Quellcodeverwaltung erstellen (svn, mercurial usw.) und diese auch auf dieselbe Weise verwalten.
- http://www.liquibase.org ist ein automatisierter Ansatz von oben.
- Ich habe einen Codegenerator geschrieben, der DAL-Anweisungen (Data Access Layer) und DDL-Anweisungen (Create Table) generiert hat. Wir haben sie zur Quellcodeverwaltung gebracht und dort gewartet. Ich denke, dedizierte Lösungen wie liquibase funktionieren möglicherweise besser.
Dieser Ansatz funktioniert gut, wenn 6. Sie DDL-Anweisungen, bei denen es sich auch um einen Code handelt, in die Quellcodeverwaltung einfügen und sie verwalten. Niemand wird Test- und Produktionsserver ohne Rücksicht ändern.
Nachteile sind, wenn Sie Änderungen an Produktions- oder Testservern aus irgendeinem Grund vornehmen, eine schnelle Fehlerbehebung, eine Änderung des Primärschlüssels usw. Sie müssen diese Änderungen auch auf den Entwicklungsserver übertragen. Da der eigentliche Entwicklungsserver Ihre Grundwahrheit ist. Nicht anders herum.
Dies ist ein sehr entwicklerorientierter Ansatz. Aber wenn Sie zum ersten Mal ein neues Modul entwickeln, funktioniert es ziemlich gut.
Antwort 2
- wenn 1 und 6 wahr sind:
Ein ähnlicher Ansatz für Antwort 1 ist die Wartung eines Entwicklungsservers. Jeder benutzt es und ändert es. Dann ist es Zeit für ein Update. Sie verwenden ein Datenbankvergleichstool. Holen Sie sich diese als Skripte, setzen Sie es unter Versionskontrolle.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
Der Unterschied zwischen Antwort 1 und Antwort 2 besteht darin, dass Sie in Antwort 1 DDL-Anweisungen für die gesamte Datenbank sammeln und speichern. In Antwort 2 müssen Sie jede Version der Änderung speichern.
- Start
- V1
- V2
- V3
- ...
Wenn Sie einer Tabelle eine Spalte hinzufügen und diese später entfernen möchten. Ihre Skripte zeigen dies in Antwort2, während Sie in Antwort1 nur die letzte Version sehen. Und Sie müssen V2 und V1 vergleichen, um Unterschiede zu erkennen. Persönlich mag ich die Antwort 1 besser, da ich Start und V3, V1 und V3 leicht vergleichen kann. In answer2 muss ich nach allen Änderungen suchen. Auch in Antwort 2 ist das Skript in der Quellcodeverwaltung in der Regel ein komplexes Skript. Schwer zu findende Informationen.
Antwort 3
Wenn 3 wahr ist. Beachten Sie, dass Sie in dieser Situation keine Einschränkung 6 haben, dh, Sie haben keine Entwicklungs-, Test- und Produktserver. Nur Produktionsserver. Mit DDL-Triggern können Sie protokollieren, welche Änderungen vorgenommen wurden. Dies wird hauptsächlich verwendet, um Menschen davon abzuhalten, ihre DDL-Zuschüsse zu missbrauchen. Wenn ein Problem auftritt, können Sie verantwortlich finden. Damit dies funktioniert, sollte sich jede Person mit ihrem Benutzerkonto verbinden und das Anwendungskonto sollte keine DDL-Berechtigungen haben. Da kennt jeder Entwickler Anwendungskonto und kann es nutzen.
Antwort 4
Wenn Sie 3 und 5 haben, beachten Sie, dass Sie in dieser Situation keine Einschränkung 6 haben, dh: Sie haben keine Entwicklungs-, Test- und Produktserver. Nur Produktionsserver. Anstelle des Triggers zum Speichern von Änderungen. Sie verwenden ein externes Tool, um nach Änderungen zu suchen und DDL-Skripte in der Quellcodeverwaltung zu speichern.
Wenn mit diesen Tools aufgezeichnet werden kann, wer Änderungen vorgenommen hat, ist dies hilfreich. Beachten Sie, dass Sie bei dieser Lösung zusätzliche DDL verlieren, die in Intervallen durchgeführt werden.