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

Hallo Frank,

so frei aus dem Bauch heraus, kannst du doch einfach ein kleines
Konvertierscript schreiben, welches ein Trennzeichen in die S=C3=A4tze
einf=C3=BCgt.

Obwohl dies nat=C3=BCrlich 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 =C3=BCber d=
ie
interne Organisation der Daten machen kann und darf.

Doch woher wei=C3=9Ft du, wie gro=C3=9F 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 =C3=BCber die
Reihenfolge der Felder machen ...


Mit freundlichen Gr=C3=BC=C3=9Fen,
Dennis Schulmeister

-
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
>
> "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.
>

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

Hallo Dieter,

> > Feste Satzstrukturen (ohne Trennzeichen) verbieten sich ja darum, weil
> > der Benutzer eines DBMS (im weitesten Sinne) keinerlei Annahmen =C3=BCb=
er die
> > interne Organisation der Daten machen kann und darf.
>
> H=C3=A4?
> 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.

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=C3=A4ssliche
Aussage =C3=BCber die Tabellenstruktur machen kann. Alles, was er wirklich
sagen kann, ist, welche Felder die Tabelle hat. Mehr nicht.


Mit freundlichen Gr=C3=BC=C3=9Fen,
Dennis Schulmeister

-
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:

>
> > Doch woher wei=C3=9Ft du, wie gro=C3=9F 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 =C3=BCber die
> > Reihenfolge der Felder machen ...
>
> Nochmal h=C3=A4?
> Nat=C3=BCrlich 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=C3=BCr eine effiziente Speicherung ge=C3=A4nder=
t 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