Migration einer bestehenden Datenbank in ein neues Schema

Hallo liebe Forumsgemeinde,

ich habe folgende Frage an euch. Durch die Umstellung von mehreren Softwareschnittstellen in einem Softwaresystem ändert sich nun auch die Beschaffenheit des Datenbankschemas. Daher müssen die bestehenden Daten in dieses neue Datenbankschema übernommen werden. Gibt es dafür ein komfortables Interface, mit dem ich die passenden Mappings, Typänderungen vornehmen kann? Bisher fällt mich nur ein, die entsprechenden Daten per SQL auszulesen, anzupassen und dann per SQL in das neue Schema zuschreiben. Dazu müsste ich aber ein entsprechendes Script erzeugen, was diese Aufgabe übernehmen kann. Diese Arbeit würde ich mir durch den Einsatz eines grafischen Interfaces gerne ersparen.

Ich hoffe, ihr könnt mir bei diesem Problem weiterhelfen.
Viele Grüße
Stephan

Ich kenne einen Anbieter, der so etwas als Software bietet. Aber das ist kostenpflichtig. Ich weiss ja nicht, wieviel Geld du investieren möchtest.

Kostenlos wäre mir da kein Tool bekannt.

bitte nicht solche unterstellungen - wir koennen uns nicht leiden - aus prinzip

ich habe folgende Frage an euch. Durch die Umstellung von mehreren Softwareschnittstellen in einem Softwaresystem ändert sich nun auch die Beschaffenheit des Datenbankschemas.

was aendert sich … ein paar mehr details koennten vielleicht helfen, das problem in luft aufzuloesen :wink:

Daher müssen die bestehenden Daten in dieses neue Datenbankschema übernommen werden. Gibt es dafür ein komfortables Interface, mit dem ich die passenden Mappings, Typänderungen vornehmen kann?

ein paar kleinigkeiten kann man mit dem PGAdmin machen …
ich wuerde aber ohnehin empfehlen mir so ALTER scripts zu bauen … weil ich inzwischen immer davon ausgehe, dass der erste wurf nicht “der beste” oder gar “DER” wurf sein wuerde … so ein script dokumentiert auch gut was du alles gemacht hast

Bisher fällt mich nur ein, die entsprechenden Daten per SQL auszulesen, anzupassen und dann per SQL in das neue Schema zuschreiben. Dazu müsste ich aber ein entsprechendes Script erzeugen, was diese Aufgabe übernehmen kann.

die zeit die du ins verstehen und einarbeiten in irgendwelche tools verschwendest - wenn du das sowieso nicht staendig machst - kannst du lieber in das script investieren … ich wette damit bist zu letztendlich schneller …

Diese Arbeit würde ich mir durch den Einsatz eines grafischen Interfaces gerne ersparen

die erfahrung hat gezeigt, dass es eierlegende wollmilchsaeue nicht gibt … ich nutze z.B. auch den PGAdmin oft nur um mir von dem irgendwelche code-schnipsel produzieren zu lassen, die ich dann haendisch anpasse … die tollen tools wissen NIE (koennen sie auch nicht) was du genau tun willst … und wenn sie es koennten, waere deren bedienung wieder so kompliziert, dass du keinen gewinn davon erzielst - es sei denn das umstricken von datenmodellen gehoert zu deinen hauptaufgaben und hat wenigstens in einer richtung (z.B. zielsystem) immer das gleiche ergebnis …

ueberdenks nochmal …

Ich kann aus meiner Sicht auch nur dazu raten, Scripts zum Konvertieren und Anpassen der Daten zu schreiben - schließlich kann so etwas beliebig komplex werden…

Ich arbeite eigentlich immer so, dass ich solche Scripts auf meiner Entwicklerdatenbank mit Testdaten entwickle. Wenn ich der Meinung bin, dass alles funktioniert, ziehe ich eine Kopie der Produktivdatenbank auf einen Testserver und lasse die Skripte dann auf die “echten” Daten los – Fehler werden natürlich immer schön in Fehlerdateien geschrieben. Wenn dort auch alles prima läuft – und erst dann – lasse ich die Skripte auf der Produktivdatenbank werkeln. Händisch mache ich dort eigentlich nichts. Das klingt zwar kompliziert - aber ich ich habe bislang (aufholzklopf) keine Datenverluste oder Downzeiten auf unserem Produktivserver durch solche Änderungen an der Struktur oder dem Inhalt gehabt.

Je nach Komplexität der Konvertierungen sind es einfache SQL-Skripte, die ich mit psql einspiele oder Perl-Skripte.

Eventuell könnte die die FME Suite von Safe-Software helfen. Ist zwar originär für Geodaten, sollte aber mit normalem auch klar kommen.

Grüssle Uwe