Suche optimale Programmieroberfläche: Delphi, .NET, PHP,...

[Silk]

Hallo,

ich arbeite täglich mit sehr großen Textdateien (ca.500MB ASCII ... >1.000.000 Zeilen).
Das Prinzip ist immer das gleiche:
- Textdatei in MySQL DB einlesen (>1.000.000 Zeilen, Spalten mit "|" getrennt)
- Referenz (ebenfalls Textdatei) in MySQL DB einlesen (>1.000.000 Zeilen)
- beim Einlesen jeweils "on-the-fly" bestimmte Spalten anpassen/generieren
- beide Tabellen vergleichen
- unterschiedliche Datensätze (teilweise nur 10-100DS) in ein bestimmtes Textformat bringen und speichern


Z.Z. arbeite ich mit XAMPP (PHP, MySQL). Ein Abgleich wie oben beschrieben dauert ca. 40 Minuten auf einem Server mit
DualCore Prozessor und 4GB RAM.

Der Internet-Explorer als Bedienoberfläche ist ziemlich unpraktisch. Die Zeit könnte auch kürzer sein.

Ich würde gern auf ein anderes System "umschwenken". Ich programmiere privat in Delphi 2005 PE. Allerdings nicht in solchen dimensionen.

Welches System könnte für solche Zwecke optimal sein? Also Text auslesen, Text bearbeiten, in DB schreiben, DB auswerten und Textdatei generieren.

Was ist einigermaßen zukunftssicher und schnell (.NET?))

Vielen Dank!

[Daniel G]

Imho ist für alles, was Datenbanken betrifft, Delphi immer noch die beste Welt Wahl...

//Edit: Was hab' ich denn da geschrieben? :gruebel: :wall:

[Silk]

Danke für die schnelle Antwort.

Habe gerade mal 500.000 DS (a 5 Spalten Text und 1x ID mit autoincrement) in ein und dieselbe DB eingelesen (nacheinander!).
Dabei waren die Zeiten ähnlich.

Jetzt will ich die Verarbeitung von Textzeilen testen. Leider gibt es in Delphi nicht so eine schöne Lösung wie die "explode-Funktion" in PHP :(

Wenn ich auf Delphi umstellen will, was für eine Version sollte man nehmen, um nächstes Jahr immer noch damit arbeiten zu können?
Es gibt ja allein von Delphi fast unendliche Versionen (TurboDelphi, Delphi2005 PE, Delphi 7,....).

Was ist mit .NET oder C#, davon hört man immer öfter?

Ist TurboDelphi wirklich kostenfrei?

[jbg]

Zitat:

Zitat von Silk

Leider gibt es in Delphi nicht so eine schöne Lösung wie die "explode-Funktion" in PHP :(

Es kommt darauf an, was du vor hast. Wenn du nur eine Textdatei mit Zeilenumbrüchen einlesen willst, geht das mit eine TStringList sehr einfach. Und wenn du unbedingt eine Explode-Funktion benötigst, dann musst du nur die Suchfunktion in diesem Forum bemühen.

Zitat:

Ist TurboDelphi wirklich kostenfrei?

Turbo Delphi Explorer ist kostenlos. Für Turbo Delphi Professional musst du Geld hinlegen.

[Sko]

Zitat:

Zitat von Silk

... Leider gibt es in Delphi nicht so eine schöne Lösung wie die "explode-Funktion" in PHP :( ...

jbg hat eine Explode-(und Implode)-Funktion geschrieben: [klick]

[Bernhard Geyer]

Zitat:

Zitat von jbg

Zitat:

Zitat von Silk

Leider gibt es in Delphi nicht so eine schöne Lösung wie die "explode-Funktion" in PHP :(

Es kommt darauf an, was du vor hast. Wenn du nur eine Textdatei mit Zeilenumbrüchen einlesen willst, geht das mit eine TStringList sehr einfach.

Ein glück hat er 4 GB Ram sonst wäre der Rechner nur mit Swappen beschäftigt.


Ich denke mal eher das hier höchstwahrscheinlich die Datenbank das bremsende Element ist. Hast Du schon folgendes gemacht:

- Verwendung von Prepared Statements und Parametern?
- Keine Transkationstabellentyp verwenden (z.B. InnoDB)
- Falls möglich (neue MySQL-Version) Verwendung von Stored Procedures.
- Wenn keine Abhänigkeiten der Datensätze untereinander vorhanden sind: Threads verwendet?

Für die "pumpende" Anwendung ist es egal ob sie unter .NET, Win32 oder Java auf die Datenbank wartet.

[Silk]

...werde demnächst die Performance zw. den beiden Explode-Funktionen vergleichen.

Ich denke auch, dass die DB der Flaschenhals ist.
Allerdings werde ich trotzdem auf Delphi (oder ähnliches) umsteigen, da mir wie gesagt die Sache mit dem InternetExplorer auf Dauer nicht gefällt.

Zitat:

- Verwendung von Prepared Statements und Parametern?
- Keine Transkationstabellentyp verwenden (z.B. InnoDB)
- Falls möglich (neue MySQL-Version) Verwendung von Stored Procedures.
- Wenn keine Abhänigkeiten der Datensätze untereinander vorhanden sind: Threads verwendet?

- zu Prepared Statements und Parametern muß ich mich informieren -> noch nie gehört
- ich verwende MyISAM Tabellen
- Stored Procedures -> das gleiche wie bei Punkt 1
- Threads habe ich noch nicht verwendet, aber da bin ich gerade dabei

[Bernhard Geyer]

Zitat:

Zitat von Silk

...werde demnächst die Performance zw. den beiden Explode-Funktionen vergleichen.

Wird vermutlich zu vernachlässigen sein ...

Zitat:

Zitat von Silk

Allerdings werde ich trotzdem auf Delphi (oder ähnliches) umsteigen, da mir wie gesagt die Sache mit dem InternetExplorer auf Dauer nicht gefällt.

Komisch :gruebel: Und das in Zeiten indene man mit AJAX die tollsten Webseiten zabert.

Zitat:

Zitat von Silk

Zitat:

- Verwendung von Prepared Statements und Parametern?
- Keine Transkationstabellentyp verwenden (z.B. InnoDB)
- Falls möglich (neue MySQL-Version) Verwendung von Stored Procedures.
- Wenn keine Abhänigkeiten der Datensätze untereinander vorhanden sind: Threads verwendet?

- zu Prepared Statements und Parametern muß ich mich informieren -> noch nie gehört
- ich verwende MyISAM Tabellen
- Stored Procedures -> das gleiche wie bei Punkt 1
- Threads habe ich noch nicht verwendet, aber da bin ich gerade dabei

[/quote]
Dann machmal (Forensuche ist hier sehr hilfreich). Ich denke wenn du die Punkte befolgst holst du noch einiges raus.

[Silk]

Prepared Statements klingen im ersten Augenblick nicht schlecht, aber wenn ich sie bei meinen 500.000 Inserts anwende, dann benötige ich dieselbe Zeit :(

Ich benutze PDO unter PHP als Test.

Kann es sein, dass es nur etwas bei SELECTs bringt? Im Internet gibt es aber auch viele Beispiele auf INSERTs.

Was mich auch in der Theorie überzeugt, aber nicht in der Praxis, sind die Transaktionen.
Also das, dass die 500.000 Insert-Befehle auf einmal nach der Schleife an die DB geschickt werden können und nicht jedesmal neu nach einem der 500.000 Querys ("beginTransaction" vor der Schleife und "Commit" danach). Habe ich das falsch verstanden?

Zu den "Stored Procedures": Macht das Sinn, wenn man eh lokal auf dem DB-Server arbeitet und so keine Netzlast erzeugt?

Ich habe folgenden PHP-Code verwendet:

<?php
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':value', $value);

$dbh->beginTransaction();
for ($i=0;$i<500000;$i++) {
$name = 'one';
$value = 1;
$stmt->execute();
}
$dbh->commit();

?>

[Bernhard Geyer]

Zitat:

Zitat von Silk

Prepared Statements klingen im ersten Augenblick nicht schlecht, aber wenn ich sie bei meinen 500.000 Inserts anwende, dann benötige ich dieselbe Zeit :(

Komisch ...

Zitat:

Zitat von Silk

Kann es sein, dass es nur etwas bei SELECTs bringt? Im Internet gibt es aber auch viele Beispiele auf INSERTs.

Sollte auch bei Inserts was bringen, da nur einmal der Executen-Plan auf DB-Seite aufgebaut werden muss.

Zitat:

Zitat von Silk

Was mich auch in der Theorie überzeugt, aber nicht in der Praxis, sind die Transaktionen.
Also das, dass die 500.000 Insert-Befehle auf einmal nach der Schleife an die DB geschickt werden können und nicht jedesmal neu nach einem der 500.000 Querys ("beginTransaction" vor der Schleife und "Commit" danach). Habe ich das falsch verstanden?

Ja. Wenn du mit MyISAM einen Tabellentyp verwendest der keine Transaktionen unterstützt ist das egal.

Zitat:

Zitat von Silk

Zu den "Stored Procedures": Macht das Sinn, wenn man eh lokal auf dem DB-Server arbeitet und so keine Netzlast erzeugt?

Der vorteil von SP's ist das der Executen-Plan schon vorliegt und auch keine Recordsets aufgebaut werden müssen (Ok, bei Inserts egal).

Zitat:

Zitat von Silk

Ich habe folgenden PHP-Code verwendet:

PHP sagt mir nicht viel aber Code schaut gut aus.