String.split() --- Java1.3

[bronks]

Hi!

Schon wieder bin ich mit Java 1.3 voll im schleudern!

Folgendes:
Eine Textdatei wird eingelesen und per Batch in eine DB geschrieben.

Zeilen, die ursprünglich so aussehen: Bronks, 1, Supermarkt sollen später so aussehen: 'Bronks', 1, 'Supermarkt'.
D.h. der String muß gesplittet werden; bei bestimmten Feldern die Hochkomma eingefügt werden und dann das ganze wieder zusammengefügt werden; in ein SQL gepackt werden und FIRE ... Das nur zur Info und evtl. hat konkret dafür jemand eine andere Idee!?!

Das Hauptproblem liegt wieder mal darin, daß ich im 1,3er Java keine passende Funktion zum splitten von Strings finde. Kann mir bitte jemand einen Tip geben, wie ich es schaffe den String bei jedem komma auseinanderzureißen?

Danke!

Bronks

 

[Bleiglanz]

StringTokenizer

 

[mic_checker]

vielleicht könntest du nen StringTokenizer verwenden, wenn man split verwenden kann sollte man es zwar benutzen, aber in deinem Fall wäre es wohl eine einfache Möglichkeit.

edit:
2 late

 

[KSG9|sebastian]

was soll das programm genau machen ?
dient es nur dazu, um "saubere" sqls zu generieren ?

wenn ja, dann splitte anhan des Kommas mit dem StringTokenizer (wie erwähnt) und benutz dann preparedStatements, dann kannst du dir den Aufwand sparen alles zu maskieren...

 

[bronks]

@all:
Danke!

... "saubere" sqls ... preparedStatements...

Es sind ca. 90000 inserts. Vorgestellt habe ich mir das so: In einer Transaktion werden im Batch diese 90000 inserts losgeschickt. --- Performancemäßig müßte das eigentlich am günstigsten sein!??! Die Überraschung wird groß sein, wenn 90000 inserts für den Batch zu viel sind.

Ich habe keine Möglichkeit gefunden im Batch PreparedStatement oder etwas ähnliches zu benutzen, obwohl es, wie von Dir erwänht, sehr angenehm wäre. Ich kann es nicht mehr finden, aber in den Sun-Foren wurde letzten Herbst ein Thema durchgekaut, bei dem es auch um einen Masseninsert mit PreparedStatement ging. Dabei hat sich herausgestellt, daß u.U. PreparedStatement nicht immer Performancevorteile bringt, sonder sich auch als echte Bremse ergeben kann. Grund: Bisher ein Rätsel.

 

[KSG9|sebastian]

ja..aber ich denke mal, dass du 90000 inserts nicht jeden zweiten tag auf die datenbank loslässt, oder ? von dem her wäre es wohl geschickter die performance einbusen in kauf zu nehmen, sich dafür aber das ganze maskieren sparen (dafür brauchst du wahrscheinlich mehr zeit als du durch prepared statements verlierst)

 

[Bleiglanz]

90000 INSERTS

in einer Transaktion ist ziemlicher Irrsinn (denk mal drüber nach), mach das nur wenns unbedingt sein muss

 

[Gast]

ähm...warum 1.3, knall 1.5 drauf und fertig ist der lack.

Es gibt viele unsinnige Threads, das hier ist ein doppelunsinniger Thread - davon gibt's nur wenige!

 

[Guest]

ähm...warum 1.3, knall 1.5 drauf und fertig ist der lack.

Es gibt viele unsinnige Threads, das hier ist ein doppelunsinniger Thread - davon gibt's nur wenige!

Wenn der Admin sagt, daß 1.3 drauf ist und so lange drauf bleibt, bis 100%ig geklärt ist, daß 1.5 zum AS und den laufenden Apps kompatibel ist, dann wird so lange für 1.3 entwickelt ...

 

[bronks]

Uuppps ... Der gast von 5:40 Uhr war ich.

Mit dem Tokenizer habe ich es jetzt fertiggebracht. Das ganze ist recht umständlich. Wenn nämlich zwischen 2 Delimitern nichts steht, dann gibt es auch kein Token, nicht mal eines mit NULL und ich mußte das ganze mit Ausgabe der Delimiter und einigen Ifs regeln.

Die Maskierung geht eigentlich sehr schnell, aber das mit dem Batch erscheint mir nicht so optimal, weil schon bei 2000 Inserts das ganze sehr lange dauert. Ich vermute, daß Java große Probleme hat eine größere Datenmenge auf diese Weise im Speicher zu halten. An dem Projekt werde ich erst mitte nächster Woche weiterarbeiten. Sobald ich die optimalste Methode herausgefunden habe, werde ich berichten ...

 

[MPW]

Und was ist mit 1.4? naja der admin sprach...