Ich bin neugierig darauf, wie andere sich dem Problem der Pflege und Synchronisierung von Datenbankänderungen bei vielen (10+) Entwicklern ohne DBA angenommen haben? Was ich meine, ist im Grunde, dass, wenn jemand eine Änderung an der Datenbank vornehmen möchte, was sind einige Strategien, das zu tun? (d. h. ich habe ein "Car" -Modell erstellt und möchte jetzt die entsprechende DDL auf die Datenbank usw. anwenden.)
Wir sind hauptsächlich ein Python-Shop und unser ORM ist SQLAlchemy. Zuvor hatten wir unsere Modelle so geschrieben, dass die Modelle mit unserem ORM erstellt wurden, aber wir haben das kürzlich aufgegeben, weil:
Unsere Lösung für dieses Problem bestand darin, grundsätzlich eine "Gatekeeper" -Instanz zu haben, die jede Änderung in der Datenbank überprüft und alle akzeptierten Datenbankänderungen auf eine accepted_db_changes.sql -Datei anwendet, wobei die Entwickler ihre Datenbankanforderungen stellen in eine Datei proposed_db_changes.sql . Wir überprüfen diese Datei, und wenn sie aktualisiert wird, übernehmen wir alle die Änderung in unserer persönlichen Datenbank auf unserem Entwicklungscomputer. Wir erstellen keine Indizes oder Einschränkungen für die Modelle, sie werden explizit auf die Datenbank angewendet.
Ich würde gerne wissen, welche Strategien es gibt, um Datenbankschemata zu verwalten und wenn unsere vernünftig erscheint.
Danke!
Die Lösung ist eher administrativ als technisch:)
Die allgemeine Regel ist einfach, es sollten nur baumartige Abhängigkeiten im Projekt sein: - Es sollte immer eine einzige Master-Schemaquelle geben, die zusammen mit dem Projektquellcode in der Versionskontrolle gespeichert wird - Alles, was von der Änderung in der Master-Quelle betroffen ist, sollte bei jeder Aktualisierung der Master-Quelle automatisch neu generiert werden, kein manueller Eingriff erlaubt nie, wenn die automatische Generierung nicht funktioniert - entweder Master-Quelle oder Generator reparieren, nicht manuell aktualisieren der Quellcode - Alle Re-Generierungen sollten von derselben Person durchgeführt werden, die die Master-Quelle aktualisiert hat und alle Änderungen einschließlich der Master-Quelländerung sollten als eine einzige Transaktion betrachtet werden (Single Source Control Commit, Single Build / Deployment für jede betroffene Umgebung einschließlich DBs Update) / p>
Wird erzwungen, gibt dies 100% zuverlässige Ergebnisse.
Es gibt im Wesentlichen 3 mögliche Auswahlmöglichkeiten für die Master-Quelle 1) DB-Metadaten, Quellen werden nach der DB-Aktualisierung durch ein Tool erzeugt, das eine Verbindung zur Live-DB herstellt 2) Quellcode, ein Werkzeug erzeugt ein SQL-Schema aus den Quellen, wird auf besondere Weise kommentiert und dann wird SQL in der Datenbank ausgeführt 3) DDL, SQL-Schema und Quellcode werden von einem Tool erzeugt 4) eine andere Beschreibung wird verwendet (sagen wir eine Textdatei, die von einem speziellen Perl-Skript gelesen wird, das sowohl das SQL-Schema als auch den Quellcode generiert)
1,2,3 sind gleich gut, vorausgesetzt, dass das Werkzeug, das Sie benötigen, existiert und nicht zu teuer ist 4 ist ein universeller Ansatz, aber es sollte von Anfang an auf das Projekt angewendet werden und hat einen Overhead von ein paar tausend Zeilen Code in einer fremden Sprache zu pflegen
Haben Sie die SQLalchemy Migrate -Tools ausprobiert?
Sie sind speziell für die automatische Migration von Datenbankentwurfsänderungen konzipiert.
Also stimme ich richtigerweise davon aus, dass Sie Ihre db direkt auf der physischen db entwerfen? Das habe ich vor vielen Jahren gemacht, aber die Qualität der resultierenden db war ziemlich schlecht. Wenn Sie ein Modellierungswerkzeug verwenden (persönlich denke ich, dass Sybase pdesigner immer noch das beste Produkt ist, aber sich umsehen), kann jeder Änderungen am Modell vornehmen und nur seine lokalen db's nach Bedarf synchronisieren (es werden auch Dokumentationsaufgaben übernommen). Also, re Bobah's Post, der Master ist eher das Pdesigner-Modell als eine physische db.
Ist Ihre accepted_db_changes.sql -Datei eine riesige Liste von Änderungsskripten? Ich bin mir nicht sicher, ob mir die Idee gefällt, den Dateinamen zu ändern, usw. Da der Unterschied zwischen zwei db-Versionen eine sequenzielle Liste alter Skripte ist, wie wäre es mit einem Modell wie:
Wo jede Änderung (neue Datei) vor der Übergabe überprüft wird.
Eine allgemeine Regel sollte sein, bewusste Anstrengungen zu unternehmen, um einen Großteil der db-Bereitstellung in Ihren Entwicklungsumgebungen zu automatisieren. Wir haben trotz allem eine respektable Rendite für diese Arbeit bekommen. Sie können Tools wie redgate verwenden, um Ihre ddl zu generieren (es hat eine API, nicht sicher, ob es mit SQLAlchemy funktioniert). IMO, DB Änderungen sollten trivial sein, wenn Sie feststellen, dass sie blockieren dann schauen, was Sie automatisieren können.
Sie finden das Buch Refactoring Databases hilfreich, da es allgemeine Strategien zum Verwalten der Datenbank enthält und nicht nur wie Refraktor sie.
Sein System erwartet, dass jeder Entwickler eine eigene Kopie der Datenbank sowie einige allgemeine Testdatenbanken vor der Bereitstellung in der Produktion haben wird. Ihre Situation ist eine der einfacheren Situationen, die im Buch beschrieben werden, da Sie nicht über mehrere separate Anwendungen verfügen, die die Datenbank verwenden (obwohl Sie jemanden benötigen, der Datenbankmigrationen zu beschreiben weiß). Das Wichtigste ist, dass die Datenbank aus Informationen in der Quellcodeverwaltung erstellt werden kann und dass Änderungen durch kleine Migrationen beschrieben werden (siehe @ WoLpHs Antwort), anstatt nur die Änderung in der Datenbank vorzunehmen. Außerdem werden Sie die Dinge leichter finden, wenn Sie mindestens ORM & lt; - & gt; Datenbank-Tests, um zu überprüfen, ob sie noch synchronisiert sind.
Tags und Links python database postgresql sqlalchemy database-schema