Wo kann ich die .sql-Datei speichern, die meine Datenbank erstellt?

Question

Ich versuche eine Webanwendung zu entwickeln, die wie die meisten Anwendungen eine Datenbank verwendet. Um die Datenbank zu erstellen, schreibe ich eine .sql -Datei, die alle Änderungen enthält, die ich an der Datenbank mache. Ich weiß nicht, warum genau, aber in der Vergangenheit fand ich es immer schwer, meine Datenbank zu leeren oder sie später zu ändern, wenn ich feststelle, dass eine Änderung sinnvoll wäre. Da ich immer noch all diese datenbankbezogenen Sachen lerne, wird das erste Layout meiner Datenbank immer geändert. Um all diese Änderungen im Auge zu behalten, habe ich mir angewöhnt, eine .sql Datei zu erstellen.

In dieser Datei lösche ich immer alle Tabellen, die bereits vorhanden sind und alle Tabellen neu erstellen. Ich tue dies, um eine Referenz über den aktuellen Zustand meiner Datenbank immer zur Hand zu haben. Änderungen an einer Datei sind für mich wesentlich einfacher als die direkte Verwendung des Befehlszeilen-Datenbankwerkzeugs. Die erste Frage wäre wirklich: Ist das wirklich eine gute Übung oder gibt es eine andere Art Dinge zu organisieren, von denen ich noch nichts gehört habe?

Die eigentliche Frage ist: Wo kann ich diese Datei speichern? Ist es eine gute Vorgehensweise, es im selben git-Repository wie den eigentlichen Code zu speichern? Soll ich es überhaupt in git stecken? Ich denke auch an Git/Github als Cloud-Speicher, wenn meine Festplatte brennt, werden alle meine Projekte noch da sein, seit ich sie auf GitHub habe. Wenn ich die .sql Datei dort nicht habe, musste ich die Datenbank von neu gründen.

Answer 1

Die allgemeine Kategorie für diese Art von Code ist "Datenbankmigrationen." Es gibt Tools, die auf diese Aufgaben spezialisiert sind, und verschiedene Webanwendungs-Frameworks können verschiedene DB-Migrations-Tools unterstützen oder sie können ihre eigenen Funktionen haben.

Wahrscheinlich das beliebteste Tool/Suite in dieser Kategorie für Python (Modelle in SQLAlchemy implementiert) wäre Alembic. Einige der anderen Optionen umfassen Flyway, Liquibase und Sqitch. In all diesen Fällen verwalten Sie eine Abstraktion Ihres Datenbankschemas (SQL, XML, YAML) und diese Tools generieren den erforderlichen SQL - und anderen Code, um "Migrationen" von jeder Version des Schemas zum nächsten durchzuführen Geschichte Ihres Projekts. Normalerweise werden diese als Inkremente generiert. Sie beginnen mit dem anfänglichen Datenbankschema (möglicherweise vollständig leer), erstellen und initialisieren das Schema in dieser Version; Dann baue und migriere durch jeden Schritt, um die gewünschte Version zu erhalten.

Dies kann beliebig komplex werden, wenn Sie radikalere Änderungen an Ihrem Schema vornehmen. Das Hinzufügen einer zusätzlichen Spalte zu einer Tabelle ohne eine Einschränkung "NOT NULL" ist trivial. Das Hinzufügen neuer M: N-Beziehungen über "NOT NULL" -Junctionstabellen und die Migration von einem denormalisierten Schema in eine höhere Normalform kann z. B. Zwischenschritte mit sich bringen, bei denen Sie einige Einschränkungen löschen und referentielle Integritätsverletzungen durch einen Übergangszustand tolerieren müssen.

Ich empfehle dringend, diese Websites, ihre Tutorials, HOWTOs und andere Dokumentation zu lesen, um ein tieferes Verständnis dafür zu bekommen, warum diese Tools existieren und wie sie diesen Problembereich angehen.

Answer 2

Yu erfinden das Rad neu, mein Freund, Ihre Lösung ist die Versionierung des DB-Schemas. Und ja, die Änderungen sollten zu den Projektdateien hinzugefügt werden, wie fast alle Framework tun. Ich empfehle, dass Sie die folgende Frage lesen How do you version your database schema?

Answer 3

Ja, Sie sollten diesen Code unbedingt in der Quellcodeverwaltung behalten. Der genaue Speicherort des Codes im Repository liegt jedoch bei Ihnen und/oder Ihrem Entwicklungsteam oder dem Management. Einige gute Optionen wären ein install-, setup-, SQL- oder ddl-Ordner.

Answer 4

Ja, was Sie tun, ist richtig.

Vergleichen Sie mit Ruby auf Schienen: eine Datei db/schema.rb enthält das gesamte Schema. Es ist auch gut so eine komplette Datei zu haben. So können Sie beispielsweise eine neue Umgebung (z. B. eine neue Testumgebung) problemlos neu starten. Diese Datei wird offensichtlich nie in der Produktion verwendet, da sie alle Ihre Daten löschen würde.

Dann gibt es separate kleine Dateien db/migrations/20171003_add_name_to_person_table.rb oder was auch immer mit inkrementellen Änderungen an das Schema - genannt Migrationen. Diese werden verwendet, um bestehende Umgebungen zu ändern, ohne Daten zu verlieren, mit einigen Mechanismen, um sicherzustellen, dass jeder nur einmal pro DB ausgeführt wird.

In Ihrem Stadium ist es völlig in Ordnung, all dies manuell zu tun. Sie können versuchen, es später bei Bedarf zu automatisieren. Es ist gut genug, dass Sie bemerkt haben, dass hier etwas vor sich geht.

Das Zeug muss in Ihr Code-Repository, wo immer natürlich scheint. /db, /schema, /etc könnte eine Auswahl sein.