Re: [1/2 OT] MySQL Storage Files
On Thu, Feb 17, 2005 at 10:08:43AM +0100, Peter Blancke wrote:
> > der Dump macht sehr viel overhead und er dauert länger als ein
> > binäres Kopieren.
>
> Ich will mal nicht in Abrede stellen, dass das so auf Deinen
> Maschinen ist. Das ist sicherlich eine Frage der augenblicklichen
> technischen Situation. Ich habe das jeenfalls bisher noch nie
> erfahren.
Nehme ich so kommentarlos als Statement hin ;)
> >> Die Groesse dieser Dateien hat nichts gemeinsam mit den
> >> eigentlichen von Dir dort hineingefuetterten Daten.
> >
> > Soll das heißen, dass die größe nicht _identisch_ ist, mit den
> > ursprünglich an die DB übergebene Datenmenge?
>
> Nein. Sie ist nicht identisch.
ACK, sonst hätte man ja in .txt speichern können :)
> Beweis:
>
> | 0000150: 0800 0000 0550 6970 6572 0000 0000 0000 .....Piper......
> | 0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> | 0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> | 0000180: 0300 1b0d fe03 00fe 0600 0000 0a46 6973 .............Fis
> | 0000190: 6368 6572 2054 6200 0000 0000 0000 0000 cher Tb.........
>
> Da stehen folglich mehr Daten drin als die "ursprünglich an die DB
> übergebene Datenmenge".
Sieht mir nach char aus, in diesem Fall wäre varchar für die Größe
sicher vorteilhafter (noch besser wäre wohl eine Abspaltung des
Verlagsnamens, der URL, ... in eine seperate Tabelle - hat ja eigentlich
nichts mit einer Bestellung zu tun).
Aber das wird jetzt OT.
grüße
--
,''`. Hagen Kuehnel - http://HagK.de
: :' : Kopierschutz: Alle Texte sind mit Double-ROT13 verschlüsselt. UrhG §95d
`. `'` Die Umgehung des Kopierschutzes stellt eine Straftat dar. UrhG §95a
`-
Reply to: