XML-Parser
-
Hat da schon jemand Erfahrungen mit gesammelt?
Ich meine hiermit nicht den XML-Standard für Webseiten, sondern selbst definierte Tags. Dabei gibt es bis zu sechs Ebenen. Das Problem, vor dem ich jetzt stehe ist, dass ein Tag in verschiedenen Ebenen auftauchen kann. Also z.B.
<X> <NAME>Paul</NAME> <ORT>München</ORT> </X>
und
<Y> <NAME>Franz</NAME> <ORT>Berlin</ORT> </Y>
Die gewonnenen Daten sollen nach SQL exportiert werden, dazu wollte ich in einer Config-Datei jedem Tag einen Spaltennamen zuweisen, aber das geht ja wie gesagt nicht so einfach :|
-
Verschiedene Tabellen können ja gleich lautende Attribute haben, wo liegt also das Problem
MfG SideWinder
-
Du solltest Tabellenname.Spaltenname in deine SQL-Statements schreiben, wenn du mehrere Tabellen offen hast mit gleichlautenden Spaltennamen.
-
Zunächst mal soll das alles in eine Tabelle, so dass eine Spalte z.B. XName und die andere YName heißt und die Problleme ergeben sich ja für mich jetzt nicht darin die SQL-Befehle zu generieren, sondern zu erkennen, was für ein Name es jetzt ist - der Parser eben
-
Na das hast du doch schon sehr schön gemacht. Du merkst dir immer das Parent-Tag und generierst damit den Namen.
Das das alles in eine einzige Tabelle soll glaub ich zwar nicht (klingt nicht sonderlich nach 3.NF) aber seis drum...
ZB für DDL:
x_name, x_ort, y_name, y_ort
Erkennen welches Tag darüber liegt kann eigentlich jeder Parser. Schau dir mal SAX oder DOM an.
MfG SideWinder
-
3.NF hmm ja da habe ich irgendwann schon einmal was von gehört
Es handelt sich um Informationen über Sendungen von a nach b und die sollten ja eigentlich nur vom Auftraggeber abhängig sein, oder wovon könnten die noch transitiv abhängig sein?
SAX und DOM werde ich mir mal genauer anschauen
-
Also ein x_name und ein y_name in einer Tabelle klingt für mich eher nach zwei Tabellen:
SuperTable 1 x 2 y SubTable Paul München 1 Franz Berlin 2
MfG SideWinder
-
Das eine ist der Abgangs- und das andere der Empfangsort. Und es sind meist andere Orte und Empfänger. Weiß nicht, ob das ein Grund ist die Tabelle nicht zu splitten?
Ich dachte bisher eher so:
Tab1:
vonort, vonstr, vonplz, vonname, nachort, ... , gewicht, anzahl, ..., VERSENDER_IDTab2:
VERSENDER_ID, login, passwort