Monstermäßige XML-Dateien. [2]

Irgendwie half das auch nichts. split macht auch ungleich große Dateien, das machte es noch leichter. Aber jede der kleineren XML-Dateien legte erstmal den Texteditor lahm, trotz einfachem Farbschema. Benennt man eine .xml-Datei jedoch zur .txt-Datei um, dann verhält sie sich sofort deutlich kooperativer. Der Versuch eine der Dateien mit file() einzulesen führt trotzdem zum gleichen Fehler wie mit der großen Datei. Außer daß dieses Mal 36 Byte nicht untergebracht wurden. Die 20 Byte aus der vorherigen Fehlermeldung waren dann wohl nicht alle, die nicht untergebracht werden konnten. PHP muß den Versuch abgebrochen haben. Also hat das Aufteilen nichts gebracht.

Neue Idee: Mit fgets() innerhalb einer FOR-Schleife kann ich einige tausend Zeilen einlesen. Mit einer WHILE-Schleife bis feof() wird stattdessen der Prozessor voll ausgelastet, so daß kaum noch etwas passiert.

Innerhalb der Datei sind Einträge durch <entry> und </entry> kenntlich gemacht. Dazwischen kann sich eine unterschiedliche Anzahl an Zeilen befinden. Ein Eintrag besteht zwischen den beiden tags aus erst einer Nummer, dann den Schreibweisen im Japanischen (davon gibt es fast immer mehrere), danach Anmerkungen zwischen verschiedenen tags und schließlich Übersetzungen in eine von Eintrag zu Eintrag unterschiedliche Anzahl an anderen Sprachen. Natürlich können es pro Sprache auch mehrere Übersetzungen sein.

Mein neuer Plan ist nun, die Datei in einer WHILE-Schleife zu durchlaufen, ein Array mit fgets() aufzufüllen, aber das Array bei jeder Zeile, die </entry> enthält wieder zu leeren. Zwischen Füllen und Leeren des Arrays muß dann das Senden an die Datenbank erfolgen. In meinen bisherigen Wörterlisten hatte ich für jeweils einen Ausdruck mehrere Übersetzungen, das heißt die Einträge waren zwar mehrdeutig, aber doch klar, wie sie in die Datenbank einzutragen waren. Mit der Japanisch-Liste ist das nicht so klar, weil sie mehrfach mehrdeutig ist. Wahrscheinlich hat deswegen jeder Eintrag eine Nummer. Ich vermute jetzt, daß es im Sinne der Normalisierung angemessen wäre pro Nummer des Eintrages eine Tabelle mit den japanischen Schreibweisen, eine Tabelle mit den Übersetzungen und eine Tabelle mit sonstigen Anmerkungen (die in den meisten Fällen leer bliebe) zu haben, also insgesamt drei Datenbanktabellen?
Ranma

XMLReader sieht mächtig kompliziert aus. Ich habe stundenlang an der Anpassung meines Skriptes getüftelt. Mußte dafür drei Datenbanktabellen anlegen. Ich probiere es also erstmal damit. Vorerst war mein Server mit einer anderen Liste beschäftigt.

Mein Skript sieht jetzt so aus, daß für jeden XML-tag, der mehrfach vorkommen kann, ein weiteres Array existiert, in das erstmal alles hineinkommt. Dann kommen drei FOREACH-Schleifen, die alles in die drei Datenbanktabellen befördern. Die weiteren Arrays werden schließlich zusammen mit dem Haupt-Array in der WHILE-Schleife geleert.

Wahrscheinlich mache ich sowieso noch ein neues Thema, wenn ich mich daran mache, die Datenbank Woerterbuch zu normalisieren. Aber im Moment brauchte ich erstmal drei Tabellen für das Skript, sonst wäre es zu kompliziert geworden.
Ranma

Das Skript ist irgendetwas zwischen zwanzig Stunden und vierundzwanzig Stunden gelaufen. In einer der drei dadurch befüllten Datenbanktabellen sind nun über eine Millionen Einträge enthalten.

Das führte sofort zum nächsten Problem. Die Datenbank läßt sich nicht mehr exportieren. Dafür wollte ich die Exportieren-Funktion in phpMyAdmin benutzen, weil ich sonst auch garnicht wüßte wie. Aber dadurch entsteht nur noch eine 0 Byte große Datei.

Ich will die Datenbank nicht nur für eine generelle Sicherungskopie exportieren, sondern auch um sie vielleicht später mal in eine produktive Datenbank zu importieren.
Ranma

Für das Exportieren von größeren Datenbanken eignet sich das Konsolen-Tool mysqldump, z.B.:

mysqldump -u <user> -p -D <datenbank> > dump.sql

(<user> und <datenbank> entsprechend ersetzen)

Zwar dauert es unerwartet lange, ein paar Listen in meine Datenbank einzulesen, aber ich versuchte mal eine Sicherungskopie auf diese Weise anzulegen. Ergebnis:

mysqldump: unknown option '-D'

Darum versuchte ich es ohne Optionen, die mysqldump --help nicht auflistet. Das listet schon -u nicht auf. Ergebnis davon:

mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2) when trying to connect

Was kann ich da machen?
Ranma

Da war eine Datei mysql.sock von 0 Byte Größe und ohne Inhalt, in den anscheinend üblichen Verzeichnissen war keine der gesuchten Dateien, aber in /etc eine my.cnf, über die nichtmal die Größe in Erfahrung zu bringen war und wohl auch nicht funktionierte. Fast hätte ich die Dateien nicht gefunden. Unter lampp/etc ist auch noch eine my.cnf, deren Einstellungen richtig waren und die das kopieren nach /etc empfahl. Also habe ich die dortige my.cnf damit ersetzt. Seitdem funktioniert mysqldump und produzierte eine so große Datei, daß ich die nicht im Editor ansehen konnte, um zu sehen, ob das wie vorgesehen geklappt hat. Zumindest ist sie groß genug, um die Datenbank zu enthalten.
Ranma