Migrationen sind zweifellos besser als nur phpMyAdmin zu starten und das Schema willy-nilly zu ändern (wie ich es während meiner php-Tage getan habe), aber nachdem ich sie für eine Weile benutzt habe, sind sie meiner Meinung nach fatal.
Versionskontrolle ist ein gelöstes Problem. Die Hauptfunktion von Migrationen besteht darin, einen Verlauf der Änderungen in Ihrer Datenbank zu speichern. Aber das Speichern einer anderen Datei für jede Änderung ist eine ungeschickte Möglichkeit, sie zu verfolgen. Sie erstellen keine neue Version von post.rb (oder eine Datei, die das Delta darstellt), wenn Sie ein neues virtuelles -Attribut hinzufügen möchten. Warum sollten Sie eine neue Migration erstellen, wenn Sie hinzufügen möchten ein neues nicht-virtuelles Attribut?
Anders gesagt, überprüfen Sie, während Sie post.rb in die Versionskontrolle einchecken, warum nicht schema.rb in die Versionskontrolle und nimmt die Änderungen direkt an der Datei vor?
Dies ist funktional dasselbe wie das Führen einer Datei für jedes Delta, aber es ist viel einfacher mit zu arbeiten. Mein mentales Modell ist "Ich möchte, dass Tabelle X solche und solche Spalten hat (oder wirklich, ich möchte, dass Modell X solche und ähnliche Eigenschaften hat)" - warum sollten Sie daraus schließen, wie man aus dem bestehenden Schema herauskommt; Öffnen Sie einfach schema.rb und geben Sie Tabelle X die richtigen Spalten!
Aber selbst die Idee, dass Klassen Tabellen umhüllen, ist ein Implementierungsdetail! Warum kann ich nicht einfach post.rb öffnen und sagen:
Wenn Sie mit einem solchen Modell gehen würden, müssten Sie eine Entscheidung darüber treffen, was mit den vorhandenen Daten geschehen soll. Aber auch dann sind Migrationen übertrieben - wenn Sie Daten migrieren, verlieren Sie an Genauigkeit, wenn Sie die down -Methode einer Migration verwenden.
Wie auch immer, meine Frage ist, selbst wenn Sie sich keinen besseren Weg vorstellen können, sind Migrationen nicht besonders eklatant?
warum nicht überprüfen Sie scheme.rb in Versionskontrolle und die Änderungen an der Datei direkt?
Weil die Datenbank selbst nicht mit der Versionskontrolle synchronisiert ist.
Sie könnten zum Beispiel den Kopf des Quellbaums verwenden. Aber Sie stellen eine Verbindung zu einer Datenbank her, die als eine frühere Version definiert wurde, nicht zu der Version, die Sie ausgecheckt haben. Mit den Migrationen können Sie das Datenbankschema von jeder Version und in jeder Version stufenweise auf oder abstufen.
Aber um Ihre letzte Frage zu beantworten, ja, Migrationen sind irgendwie eklig. Sie implementieren ein redundantes Revisionskontrollsystem zusätzlich zu einem anderen Revisionskontrollsystem. Keines dieser Revisionskontrollsysteme ist jedoch wirklich mit der Datenbank synchronisiert.
Es gibt auch datenbezogene Probleme, die es zu berücksichtigen gilt, welche Migrationen sich lösen.
Nehmen wir an, eine alte Version meines Schemas hat eine feet und inches Spalte. Aus Effizienzgründen möchte ich das nur in eine inches -Spalte kombinieren, um das Sortieren und Suchen zu vereinfachen.
Bei meiner Migration können alle Fuß- und Zolldaten in die Zoll-Spalte (Fuß * 12 + Zoll) kombiniert werden, während die Datenbank aktualisiert wird (d. h. kurz bevor die Spalte feet entfernt wird)
Offensichtlich funktioniert dies bei einer Migration automatisch, wenn Sie die Änderungen später in Ihrer Produktionsdatenbank anwenden.
Nur um zu beschreiben, was andere gesagt haben: Migrationen ermöglichen es Ihnen, die Daten bei der Entwicklung Ihres Schemas zu schützen. Die Idee, eine einzelne schema.rb -Datei beizubehalten, ist nur solange attraktiv, bis Ihre App in Produktion geht. Danach müssen Sie die Daten Ihrer vorhandenen Benutzer bei der Änderung Ihres Schemas migrieren .
Wie es aussieht, sind sie nervig und ungenügend, aber möglicherweise die beste Option, die wir derzeit haben. Einige schlaue Leute haben ziemlich viel Zeit damit verbracht, an dem Problem zu arbeiten, und das ist bisher das Beste, was sie erreichen konnten. Nach etwa 20 Jahren der meist manuellen Kodierung von Datenbank-Versions-Updates, habe ich Migrationen sehr schnell als große Verbesserung empfunden, als ich ActiveRecord gefunden habe.
Wie Sie sagen, Versionskontrolle ist ein gelöstes Problem. Bis zu einem gewissen Punkt stimme ich zu: Es ist besonders für Textdateien sehr gelöst, weniger für andere Dateitypen und nicht wirklich sehr für Ressourcen wie Datenbanken.
Wie sehen Migrationen aus, wenn Sie sie als Versionskontrolldeltas für Datenbanken betrachten? Sie sind die Summe der Deltas, die Sie anwenden müssen, um ein Schema von einer Version zur anderen zu bekommen. Ich bin mir nicht bewusst, dass sogar Git trotz seiner Supermächtigkeit zwei Schemadateien aufnehmen kann und dafür die notwendige DDL generiert.
Soweit es den Inhalt der Tabelle im Modell erklärt, glaube ich, dass DataMapper dies tut (keine persönliche Erfahrung). Ich denke, dass es auch DDL Inferenzmöglichkeiten gibt.
"Selbst wenn Sie sich keinen besseren Weg vorstellen können, sind Migrationen nicht besonders eklatant?"
Ja. Aber sie sind weniger eklig als alles, was wir haben. Bitte lassen Sie uns wissen, wenn Sie die nicht-grobe Alternative abgeschlossen haben.
Ich nehme an, gegeben "auch wenn Sie nicht an einen besseren Weg denken können", dann, ja, im großen Plan der Dinge, Migrationen sind irgendwie eklig. So sind Ruby, Rails, ORMs, SQL, Web-Anwendungen, ...
Migrationen haben den (nicht zu vernachlässigenden) Vorteil, dass sie existieren. Grob-aber-existiert tendiert dazu, sich über Angenehm-aber-nicht-existent zu erheben. Ich bin sicher, dass es wahrscheinlich angenehme und nicht existierende Möglichkeiten gibt, um Ihre Daten zu migrieren, aber ich bin mir nicht sicher, was das bedeutet. : -)
Okay, ich werde eine wilde Vermutung hier nehmen und sagen, dass Sie wahrscheinlich ganz alleine arbeiten. In einem Gruppenentwicklungsprojekt ist die Fähigkeit jedes Einzelnen, die Verantwortung für seine Änderungen an der Datenbank zu übernehmen, die für den vom Entwickler geschriebenen Code erforderlich ist, viel wichtiger.
Die Alternative ist, dass größere Gruppen von Programmierern (z. B. 10-15 Java-Entwickler, an denen ich arbeite) am Ende auf einige dedizierte Vollzeit-Datenbankadministratoren angewiesen sind, um dies zusammen mit ihren anderen Wartungs-, Optimierungs- und anderen Aufgaben zu erledigen / p>