Thread SQL-DB-Dump lesen und konverieren (18 answers)
Opened by topeg at 2014-03-14 02:28

topeg
 2014-03-14 20:14
#174113 #174113
User since
2006-07-10
2611 Artikel
BenutzerIn

user image
2014-03-14T11:55:56 rosti
Dateien sind mit Perl generell einfach zu erzeugen. Letztendlich gehts darum, Datenstrukturen auf Byte-Ebene abzubilden ohne Informationsverlust. In DB-Feldern können sowohl NULL-Werte als auch Leerstrings vorkommen, dass muss nach einem Transport der Daten reproduzierbar sein, wie machst Du das in einer CSV?

Der Parser von mir Nimmt was im SQL-Stament steht, wenn da ein leerer sing ist, wir ein leerer Sing in das CVS geschrieben, Wenn dort "NULL" steht steht auch im CSV "NULL"

2014-03-14T11:55:56 rosti
Dann hätten wir noch, bei einer textlichen Strukturierung, die Frage nach dem Feld-Trennzeichen zu klären, im einfachsten Fall wird dieses Zeichen in Nutzdatenfeldern maskiert.

Der Feldtrenner ist "," wenn im Datensatz selber "," vorkommt wird er mit '"' Gequotet und das Komma damit entwertet. Kommt ein '"' vor wird der Datensatz gequotet und das '"' durch duplizieren ('""') entwertet. Das folgt der CSV-Spezifikation ähnliches wird mit Zeilenumbrüchen gemacht.

2014-03-14T11:55:56 rosti
Aus Letzerem ergibt sich im Falle einer menschenlesbaren Darstellung wiederum eine Anforderung an den Editor, wobei die Entscheidung ob eines human readable format höchstens im zweistelligen Megabytebereich getroffen wird und bei Datenmengen, die an Gigabytes heranreichen völlig indiskutabel ist.

Es ist aber Potentiell besser lesbar als ein Binärformat, das man nur wider mit einem speziellen Parser lesen kann. Die Frage ist einfach, was will man später mit den Daten machen. Wenn man sie direkt weiterverarbeiten will dann sollten man das Modul aus dem Script nehmen und die Weiterverarbeitung direkt nach dem Parsen machen. Wenn man aber einfach nur erst mal die Daten haben will um sie in einer Tabellenkalkulation ansehen zu können ist CSV kein so schlechtes Format.

2014-03-14T11:55:56 rosti
Praktisch ist das die erste Entscheidung:
Sollen Daten dargestellt oder transportiert werden?

Was redest du Ständig von Transport? Was genau willst du von mir? Ich kann Das ganze auch wider zurück nehmen. Ich dachte nur das es anderen ein Hilfe sein könne. Wenn du meinst das mein Code völliger Müll ist, dann lösche ich es halt.


2014-03-14T11:55:56 rosti
Dann wäre noch was: Textlich strukturierte Daten erfordern einen Parser und der kann erst dann arbeiten, wenn die Daten komplett im Hauptspeicher liegen. Es sei denn, die CSV kann zeilenweise abgearbeitet werden, woraus sich die nächste Frage ergibt, nämlich die, wie in Nutzdaten vorhandene Zeilenumbrüche nach CSV transformiert werden sollen. Freilich kann ein Datensatz in einer CSV auch auf mehrere Zeilen abgebildet sein, aber wozu überhaupt einen Zeilenumbruch als Trennzeichen für Datensätze?

Du schreibst Unsinn. Schau dir meinen SQL-Parser an, ich habe nur "\n" als Ende einer Zeile gewählt weil die meisten SQL-Dumps in der Beziehung eine Beschränkung der Zeilenlängen haben. Genauso gut könne ich eine eine feste Anzahl von Bytes lesen und die verarbeiten, die Anpassungen wären minimal. Ein Parser muss nicht alles lesen um die Elemente Parsen zu können, er muss nur immer wissen im welchen "Status" sich der gelesenen String sich befindet. Ob er sich innerhalb eines Befehls eines Datensatz, eines Kommentars etc. befindet.

2014-03-14T11:55:56 rosti
Nächste Frage: Datentypen in einer CSV-Datei.... Alles in Allem ist ein Transport über CSV o.a. mit textlich strukturierten Mitteln erzeugten Dateien alles Andere als einfach. Sequenzen erfordern auch keinen Parser, das Lesen einer Sequenz beginnt ummittelbar mit den ersten Bytes, das ist CPU und RAM-gefällig.

Und das kannst du auch einfach an Eine Tabellenkalkulation geben, um zu schauen was du da eigentlich hast. Ja bitte du hast recht, das CSV nicht das nonplusultra der Datenspricherung ist. Darum ging es mir auch gar nicht. Ich hatte einen SQL-Parser geschrieben und dachte mir. "Hey wäre sicher doch nützlich wenn man damit SQL-Dump-Tabellen als CSV speichern könne, das sind für mich 30 zusätzliche Zeilen zum Parser. Und man kann auch gleich sehen, wie man den Parser benutzen kann."

2014-03-14T11:55:56 rosti
Argumente wie Kompatibilität und Portierbarkeit sind ebenfalls nicht an CSV gebunden, das lässt sich auch mit proprietären Sequenzen lösen. Portierbarkeit: Unterschiedliche Plattformen reden Bytes. HTTP: Übertragen werden Bytes. FTP, Sockets... Bytesemantics. Nicht umsonst gibt es Schichtenmodelle.

Wer sagt das die Daten irgendwohin transferiert werden sollen? Ich habe nie geschrieben, das sie irgendwohin transferiert werden sollen. Ich habe nur einen einfachen SQL-Parser geschrieben und darum ein kleines Script was CSV erzeugt. Mir ist es völlig egal wohin welche Daten auch immer transferiert werden. CVS ist einfach zu erzeugen und kann von vielen Programmen sinnvoll gelesen werden.

Man nimmt den SQL-Dump den man lokal hat. Sagt dem Script in welches Verzeichnis die CSV Dateien geschrieben werden sollen und das Script rödelt den Dump durch. Wenn du mehr willst Passe das Script an. Ich verstehe nun wirklich deine Aggression nicht.

2014-03-14T11:55:56 rosti
Schönes Wochenende!

Dir Auch!

View full thread SQL-DB-Dump lesen und konverieren