Import von Dateien mit fester Satzlaenge

in aelteren versionen von mysql funktionierte der import von dateien
fester satzlaenge (undokumentiert?), wenn man sie mit

"LOAD DATA INFILE foo INTO bar FIELDS TERMINATED BY '' FIELDS ENCLOSED BY ''"

in eine strukturgleiche tabelle uebernahm.

die dokumentation schliesst das jetzt ausdruecklich aus, und ein erster
vorsichtiger test mit der bankleitzahlentabelle bestaetigt auch, dass es
nicht mehr funktioniert.

da ich meine alten konvertierungstools eigentlich langsam verklappen
moechte, frage ich mich, ob es einen einfachen (und tunlichst
dokumentierten) weg gibt, solche dateien zukuenftig direkt zu
importieren.

--
frobnicate foo

Re: Import von Dateien mit fester Satzlaenge

Hallo Frank,

so frei aus dem Bauch heraus, kannst du doch einfach ein kleines
Konvertierscript schreiben, welches ein Trennzeichen in die Sätze
einfügt.

Obwohl dies natürlich deiner folgenden Aussage widerspricht:

> da ich meine alten konvertierungstools eigentlich langsam verklappen
> moechte

Feste Satzstrukturen (ohne Trennzeichen) verbieten sich ja darum, weil
der Benutzer eines DBMS (im weitesten Sinne) keinerlei Annahmen über d=
ie
interne Organisation der Daten machen kann und darf.

Doch woher weißt du, wie groß ein Datensatz einer Tabelle wirklic=
h ist
oder wie er intern abgelegt wird? Nach der reinen Lehre, welche nicht
immer gelebt wird, darfst du ja nicht einmal Annahmen über die
Reihenfolge der Felder machen ...


Mit freundlichen Grüßen,
Dennis Schulmeister

- =20
Volle Kontaktdaten auf WikiBerd: (http://ncc-1701a.homelinux.net)

http://www.windows3.de - http://www.denchris.de
http://www.audiominds.com - http://www.motagator.net/bands/65


On Wed, 2007-11-28 at 13:28 +0100, frank paulsen wrote:
> in aelteren versionen von mysql funktionierte der import von dateien
> fester satzlaenge (undokumentiert?), wenn man sie mit=20
>=20
> "LOAD DATA INFILE foo INTO bar FIELDS TERMINATED BY '' FIELDS ENCLOSED BY=
''"=20
>=20
> in eine strukturgleiche tabelle uebernahm.=20
>=20
> die dokumentation schliesst das jetzt ausdruecklich aus, und ein erster
> vorsichtiger test mit der bankleitzahlentabelle bestaetigt auch, dass es
> nicht mehr funktioniert.
>=20
> da ich meine alten konvertierungstools eigentlich langsam verklappen
> moechte, frage ich mich, ob es einen einfachen (und tunlichst
> dokumentierten) weg gibt, solche dateien zukuenftig direkt zu
> importieren.
>=20

Re: Import von Dateien mit fester Satzlaenge

Dennis Schulmeister wrote:

> Feste Satzstrukturen (ohne Trennzeichen) verbieten sich ja darum, weil
> der Benutzer eines DBMS (im weitesten Sinne) keinerlei Annahmen über die
> interne Organisation der Daten machen kann und darf.

Hä?
Frank meint die Daten, die geladen werden sollen und nicht die interne
Struktur der Tabellen. Und da laden sich Daten mit fester Breite
einfacher/effizienter als mit variabler Breite.

> Doch woher weißt du, wie groß ein Datensatz einer Tabelle wirklich ist
> oder wie er intern abgelegt wird? Nach der reinen Lehre, welche nicht
> immer gelebt wird, darfst du ja nicht einmal Annahmen über die
> Reihenfolge der Felder machen ...

Nochmal hä?
Natürlich ist die Reihenfolge der Felder in einer Tabelle festgelegt
durch die Reihenfolge der Spalten in der Definition. Ob und wie diese
Reihenfolge dann intern für eine effiziente Speicherung geändert wird,
ist Sache des DBMS. Es gibt auch Systeme, die Daten spaltenbasierend
speichern, trotzdem bekomme ich bei einem select * die Spalten immer in
der definierten Reihenfolge.

Dieter

Re: Import von Dateien mit fester Satzlaenge

Hallo Dieter,

> > Feste Satzstrukturen (ohne Trennzeichen) verbieten sich ja darum, weil
> > der Benutzer eines DBMS (im weitesten Sinne) keinerlei Annahmen üb=
er die
> > interne Organisation der Daten machen kann und darf.
>=20
> Hä?
> Frank meint die Daten, die geladen werden sollen und nicht die interne=20
> Struktur der Tabellen. Und da laden sich Daten mit fester Breite=20
> einfacher/effizienter als mit variabler Breite.

Aber er schreibt ja, dass das Laden bisher nur funktioniert hat, weil
die Satzstruktur der Datendatei identisch war mit der internen Struktur
der Tabelle im DBMS.

Mein Einwand daraufhin ist, dass er eigentlich gar keine verlässliche
Aussage über die Tabellenstruktur machen kann. Alles, was er wirklich
sagen kann, ist, welche Felder die Tabelle hat. Mehr nicht.


Mit freundlichen Grüßen,
Dennis Schulmeister

- =20
Volle Kontaktdaten auf WikiBerd: (http://ncc-1701a.homelinux.net)

http://www.windows3.de - http://www.denchris.de
http://www.audiominds.com - http://www.motagator.net/bands/65


On Wed, 2007-11-28 at 21:41 +0100, Dieter Noeth wrote:
> Dennis Schulmeister wrote:

>=20
> > Doch woher weißt du, wie groß ein Datensatz einer Tabelle wir=
klich ist
> > oder wie er intern abgelegt wird? Nach der reinen Lehre, welche nicht
> > immer gelebt wird, darfst du ja nicht einmal Annahmen über die
> > Reihenfolge der Felder machen ...
>=20
> Nochmal hä?
> Natürlich ist die Reihenfolge der Felder in einer Tabelle festgelegt=
=20
> durch die Reihenfolge der Spalten in der Definition. Ob und wie diese=20
> Reihenfolge dann intern für eine effiziente Speicherung geänder=
t wird,=20
> ist Sache des DBMS. Es gibt auch Systeme, die Daten spaltenbasierend=20
> speichern, trotzdem bekomme ich bei einem select * die Spalten immer in=20
> der definierten Reihenfolge.
>=20
> Dieter