[ex³]

Nabend miteinander,

Ich habe hier eine kleine Anwendung mit ca. 10 Tables mit insgesamt 2000 Zeilen. Da mein Script ein bisschen kritisch ist und ich es demnächst updaten muss werde ich für die alte Version einen XML Backup machen wo ich nach aufspielen der neuesten Script Version, den XML Backup der Vorgängerversion importieren kann. Das geht schneller als die alten Tabellenstrukturen mit Inhalt an die neue Script Version anzupassen.

Nun hatte ich mir gedacht ich gehe hin und mache aus den Tabellendaten jeder einzelnen Tabelle eine XML Datei. Nachdem alle Dateien erstellt worden sind packe ich die in ein ZIP Archiv und erzwinge den Download.

In der neuen Scriptversion lade ich dann das ZIP Archiv hoch, das wird entpackt, jede XML wird sicherheitshalber nochmal gegen ein DTD Schema geprüft und falls alles passt wir per Transaktion die jeweiligen Tabellen befüllt.

Was haltet ihr davon? Jetzt mal vom Aufwand abgesehen. Umsetzen würde ich das mit ein paar PEAR.

Oder sollte ich (wenn überhaupt) die Normalisierung der Tabellen komplett über den Haufen werfen, alles in eine riesige XML Datei packen (statt 2-6 XML Dateien je Tabelle) und beim import wieder alles auseinander frimeln?

[dr.e.]

Ich frage mich, warum du überhaupt XML verwenden möchtest, ein einfacher MySQL-Dump hat um einiges weniger Meta-Zeichen und du musst bei der Speicherung nicht auf Escape-Sequenzen Acht geben. Sollte sich während des Updates etwas an den Tabellen ändern, kann man ganz einfach auf Basis der SQL_Statements ein Mapping generieren. Der Import geht per

mysql --user="123" --password="456" dbname < /path/to/dump/file.sql

dann ganz einfach von der Hand. Zudem musst du bei XML-Operationen bedenken, dass PHP die komplette Struktur des XMLs in den Speicher laden muss, ehe dies in die Datenbank geschrieben werden kann. Hier sind "out of memory exceptions" bereits vorprogrammiert.

[MrNiceGuy]

Nunja, bei 2000 Zeilen wird es wohl nicht gleich zu einem Speicherüberlauf kommen.

Dennoch bin ich persönlich der Meinung, dass man sich überlegen sollte, ob ein Import-Script überhaupt notwendig ist, da man in der Regel nur ein Mal von einem alten Script auf ein neues umzieht (außer, es wird für verschiedene Projekte genutzt). Denn egal, ob du XML oder SQL verwendest: Du musst entweder beim Export (SQL) oder beim Import (XML) die Daten umbauen, damit sie in die neuen Tabellen passen. Ich persönlich mache es dann eigentlich so, dass ich die SQL-Commands in PMA baue, um die Daten von der einen Tabelle in die andere zu bekommen und sobald die genau so funktioniert, wie ich das haben will, speichere ich sie in einer Text-Datei ab. Dann kommt die nächste Tabelle dran. Solange, bis ich alle Tabellen importiert habe (übrigens mit "INSERT INTO ... SELECT ..."). Danach speichere ich die Text-Datei als eine .sql-Datei und nutze diese dann beim Umzug für den Import der Daten. Vorteil: Ich ziehe direkt die Daten aus der Datenbank und muss nicht ggf. 20 MB an Daten per Upload auf den Server schieben und ich kann die Datei für jedes Projekt nutzen, welches die selben Scripte verwendet.

Ich finde das persönlich etwas praktischer und einfacher, als nachher manuell aus den XML-Daten die SQL-Commands zusammen bauen zu müssen, denn wenn in der neuen Tabellenstruktur auf ein Mal in einer Tabelle Daten aus mehr als einer alten Tabelle zusammengeführt werden, muss man die Funktionalität von JOINs im SQL-Command (bzgl. "INSERT INTO ... SELECT ...") für das XML selber realisieren. Ein wenig aufwendig für ein Script, das in der Regel sehr selten genutzt wird.

[ex³]

Das mit SQL Befehlen in einer Textdatei speichern ist auch eine gute Idee, also für eine einmalige Aktion. Bisher hatte ich das immer so gemacht, wenn die neue Tabellenstruktur steht und das neue Script ist online, dann nehme ich die alte Tabellenstruktur und bastele diese um, damit sie genauso ist wie die neue Tabellenstruktur ist, allerdings ist das nicht so das Wahre da in der Zeit mit dem Script nicht gearbeitet werden kann und ich beim umbauen vielleicht einen Fehler mache. Das wollte ich halt mit einem XML Import/Export vermeiden.

Aufwändig ist die Sache schon.

[MrNiceGuy]

Nunja, das ist immer das Problem bei einer Datenübernahme.

Wenn du im Vorfeld, also bevor auf das neue Script umgestellt wird, die SQL-Commands fertig hast, dann legst du vor dem Umzug eine neue DB an, lädst das neue Script hoch, richtest es für die neue DB ein, sperrst das alte Script, übernimmst die Daten, testest die neue Version und schaltest die dann frei. Wie genau du das dann machen musst ist natürlich auch abhängig davon, wie du auf deinen Webspace zugreifen kannst, denn am Einfachsten ist es, die neue Version erstmal in einen anderen Ordner zu schieben und dann per SSH einfach die Dateien nach der Übernahme und dem Test zu verschieben, das dauert dann nur wenige Sekunden.