| von subjective |
| Es ist in diesem Fall die einfachste Variante. Denn ein solcher SQL-Dump muss nicht nur Daten einfügen, sondern zB auch vorher die Tabellen leeren und nach dem Einfügen diverse Daten aggregieren. Also warum sollte ich die SQL-Statements bei jedem Einfügen erzeugen? Warum sollte ich für Sicherheitskopien drei statt einer Datei verwalten? |
| von skc.tiddy |
warum einfach, wenn aus kompliziert geht.
die daten speichern ist interessant, aber doch keine statements.
BLAH!!!! |
| von subjective |
Ich mache das auch bei einem Projekt - der User lädt 3 csv-Dateien über ein WebInterface hoch. Daraus erzeuge ich eine Textdatei (.sql). Der User kann dan auswählen welche der SQL-Dateien "aktiviert" werden soll. Zur Aktivierung wird der Dump dann mittels mysql-Binary in die Datenbank eingetragen. Das mysql-Binary ist deutlich schneller beim Zerlegen und Ausführen der SQL-Anweisungen als eine PHP-Lösung. Außerdem habe ich so eine "Backup-Lösung" in Form der älteren SQL-Dateien.
Allerdings schreibe ich keine "Variablennamen" in die Datei, sondern nur das fertige SQL (mit Escaping, Löschen der alten Daten, Aggregieren diverser Zwischenergebnisse, ...). PHP-Variablen haben in dem SQL nix zu suchen. |
| von HoRnominatoR |
| warum denn erst zwischenspeichern? |
| von MarkusStruebel |
Nein,
sie werden aus Text und Variablen zusammen gesetzt. Also z. B.:
INSERT INTO table VALUES ('$data[1][1]', '$data[1][2]', '$data[1][3]');
INSERT INTO table VALUES ('$data[2][1]', '$data[2][2]', '$data[2][3]');
INSERT INTO table VALUES ('$data[3][1]', '$data[3][2]', '$data[3][3]');
INSERT INTO table VALUES ('$data[4][1]', '$data[4][2]', '$data[4][3]');
usw.
Meine Frage ist nur: Soll obiger Text in eine statement.sql oder direkt in die Datenbank?
|
|
