Hallo alle!
Macht es irgendeinen Sinn die Längen der VARCHARS (bzw. CHARS) auf 2,
4, 8, 16, 32, 64 und/oder 128 zu setzen um dabei z.B. bei der
Speicherung oder Verarbeitung irgendwelche Vorteile zu haben oder ist
das prinzipiell "wurschtegal"? Ich habe das irgendwann einfach mal so
gemacht, warum sehe ich aber nicht (mehr)...
Bitte mal etwas dazu schreiben, wenn hier jemand mehr weiß...
Danke und Gruß
Karsten
Karsten Wutzke wrote:
>
> Macht es irgendeinen Sinn die Längen der VARCHARS (bzw. CHARS) auf 2,
> 4, 8, 16, 32, 64 und/oder 128 zu setzen um dabei z.B. bei der
> Speicherung oder Verarbeitung irgendwelche Vorteile zu haben oder ist
> das prinzipiell "wurschtegal"? Ich habe das irgendwann einfach mal so
> gemacht, warum sehe ich aber nicht (mehr)...
Ich wüßte keinen vernünftigen Grund, warum man das tun sollte. Du
belegst ja mit jedem Zeichen ein komplettes Byte (oder mehrere; je nach
Zeichensatz). Würdest du auf Bit-Ebene arbeiten, wäre dein Ansinnen
zumindest keine Verschwendung, weil ja ohnehin nicht weniger als ein
Byte belegt werden kann. Aber auf Byte-Ebene ist es wohl ziemlich wurscht.
Es gibt Gedankenmodelle (ich hab das noch nie selber ausprobiert), die
besagen, daß auch bei VARCHAR die Länge einen Einfluß auf die
Performance hat. Andere besagen, daß es völlig egal ist. Im Zweifel
würde ich die Spalte erst mal mit 255 Zeichen definieren und schauen,
was passiert. Auf eine "sinnvolle" Länge kürzen kann man ja später immer
noch, wenn es tatsächlich zu viel Performance frisst.
Bei CHARs dagegen würde ich das genau überlegen. Hier frisst dir jedes
Zeichen zuviel sofort Platz auf der Platte (bei den aktuellen
Plattenpreisen wohl vernachlässigbar). Außerdem mußt du im Zweifel
größere Sprünge auf der Platte machen, als unbedingt nötig. Und daß das
ordentlich Performance frisst, werden dir die Entwickler von IBMs OS/400
gerne bestätigen.
Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal
On 13 Feb., 20:13, Dominik Echterbruch
> Karsten Wutzke wrote:
>
> > Macht es irgendeinen Sinn die Längen der VARCHARS (bzw. CHARS) auf 2,
> > 4, 8, 16, 32, 64 und/oder 128 zu setzen um dabei z.B. bei der
> > Speicherung oder Verarbeitung irgendwelche Vorteile zu haben oder ist
> > das prinzipiell "wurschtegal"? Ich habe das irgendwann einfach mal so
> > gemacht, warum sehe ich aber nicht (mehr)...
>
> Ich wüßte keinen vernünftigen Grund, warum man das tun sollte. Du
> belegst ja mit jedem Zeichen ein komplettes Byte (oder mehrere; je nach
> Zeichensatz). Würdest du auf Bit-Ebene arbeiten, wäre dein Ansinnen
> zumindest keine Verschwendung, weil ja ohnehin nicht weniger als ein
> Byte belegt werden kann. Aber auf Byte-Ebene ist es wohl ziemlich wurscht.
>
> Es gibt Gedankenmodelle (ich hab das noch nie selber ausprobiert), die
> besagen, daß auch bei VARCHAR die Länge einen Einfluß auf die
> Performance hat. Andere besagen, daß es völlig egal ist. Im Zweifel
> würde ich die Spalte erst mal mit 255 Zeichen definieren und schauen,
> was passiert. Auf eine "sinnvolle" Länge kürzen kann man ja später =
immer
> noch, wenn es tatsächlich zu viel Performance frisst.
snip
>
> Grüße,
> Dominik
OK danke für die Hilfe. Ich werde die VARCHARS trotzdem begrenzen, da
meine GUI-Felder (HTML ) aus den Metadaten generiert werden
und ein VARCHAR(20) wesentlich kürzer ist, als ein VARCHAR(255)...
Gruß
Karsten
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
..oO(Andreas Kretschmer)
>begin Dominik Echterbruch
>
>> Plattenpreisen wohl vernachlässigbar). Außerdem mußt du im Zweifel
>> größere Sprünge auf der Platte machen, als unbedingt nötig. Und daß das
>
>Andere Systeme ;-) lagern hier in TOAST-Tables aus, während MySQL es
>wohl alles als Klumpen speichert. Tja...
Du hast den Toast, wir die Butter.
SCNR
Micha
Andreas Kretschmer wrote:
>
>>Plattenpreisen wohl vernachlässigbar). Außerdem mußt du im Zweifel
>>größere Sprünge auf der Platte machen, als unbedingt nötig. Und daß das
>
> Andere Systeme ;-) lagern hier in TOAST-Tables aus, während MySQL es
> wohl alles als Klumpen speichert. Tja...
Die Beschränkung "im Zweifel" hast du ja offensichtlich übersehen. Aber
auch verbranntes Brot hilft dir nicht viel, wenn die Daten quer über die
Platte verteilt liegen ;)
Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Andreas Kretschmer wrote:
>
> http://www.postgresql.org/docs/8.2/interactive/storage-toast .html
Interessante Idee.
Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal
Andreas Kretschmer!
> Andere Systeme ;-) lagern hier in TOAST-Tables aus, während MySQL es
> wohl alles als Klumpen speichert. Tja...
Bei MySQL hängt es von der Storage Engine ab (andere Systeme haben ja nur
eine).
Postgres braucht TOAST nur deshalb, weil es eine feste Pagegröße von 8k
hat und deshalb ohne TOAST der Speicherplatz für eine Zeile ziemlich
niedrig begrenzt ist.
InnoDB hat auch eine feste Pagegröße (16k), speichert aber bei großen
Feldern nur den Anfang an dieser Stelle und lagert den Rest auch aus. Es
gibt halt kein cooles Akronym wie TOAST dafür, und es ist auch nicht so
murksig wie eine Zeile auf mehrere Zeilen aufzuspalten wie bei TOAST.
MyISAM hat keine feste Pagegröße und braucht daher sowas wie TOAST nicht.
Gruß
Daniel
Dominik Echterbruch!
> Es gibt Gedankenmodelle (ich hab das noch nie selber ausprobiert), die
> besagen, daß auch bei VARCHAR die Länge einen Einfluß auf die
> Performance hat. Andere besagen, daß es völlig egal ist.
Wenn MyISAM als Storage Engine verwendet wird, macht es einen Unterschied,
ob alle Records die selbe Größe haben - das ist eventuell schneller als
Records variabler Größe. Der Default für Tabellen mit Spalten variabler
Länge ist, dass die Records nicht die selbe Größe haben. Wenn VARCHAR
verwendet wird, kann das aber immer noch vom Benutzer vorgegeben werden
(ALTER TABLE...ROW_FORMAT=FIXED).
Umgekehrt wird bei ROW_FORMAT=DYNAMIC bei VARCHAR nur das gespeichert, was
auch belegt wird, d.h. auch ein VARCHAR(200)-Feld mit einem drei
Buchstaben langen Wert wird nur den Platz für ein VARCHAR(3)-Feld belegen.
Aber ob die Länge eine Zweierpotenz ist, hat keinen Einfluss.
Gruß
Daniel