Varchar immer aufs höchste setzen?
T-Rex
Varchar immer aufs höchste setzen?
T-Rex
Moin,
bin gerade dabei ein Feld, welches mal wieder zu klein geworden ist (Varchar(64) auf Varchar(128)) zu erhöhen.
*off*
Obwohl man bei Varchar jede beliebige Bytezahl benutzen kann, bleibe ich immer auf der Binären Schiene hängen. Geht euch das auch so?
*on*
Wäre es nicht klüger immer die höchstmenge von ca. 65.000 (oder?) zu nehmen? Ich meine, Varchar holt sich doch sowieso nur soviele Bytes wie es braucht?
Gruß
der Nagel mit Kopf
T-Rex
-
Tach!
Obwohl man bei Varchar jede beliebige Bytezahl benutzen kann, bleibe ich immer auf der Binären Schiene hängen. Geht euch das auch so?
Mir nicht.
Wäre es nicht klüger immer die höchstmenge von ca. 65.000 (oder?) zu nehmen?
Es gibt die Höchstmenge von 65535 Bytes pro Row. Ein Varchar benötigt bei UTF-8 bis zu 3 Byte, weswegen die Höchstmenge von einem UTF-8-Varchar-Feld bei 21844 liegt - vorausgesetzt es ist das einzige Feld in der Tabelle. Kommen weitere hinzu, sinkt die Höchstgrenze pro Feld. Nicht mitgezählt werden übrigens BLOB- und TEXT-Felder. Es ist also schon rein technisch nicht möglich, gleich von Anfang an die Höchstgrenze zu nehmen. Es gibt übrigens auch "silent column type changes", da wird ein zu großes Feld stillschweigend zu einem der TEXT-Typen geändert. Jetzt könntest du noch auf die Idee kommen, gleich TEXT zu verwenden. Damit holst du dir aber nur weitere Nachteile ins Boot.
dedlfix.
-
Obwohl man bei Varchar jede beliebige Bytezahl benutzen kann, bleibe ich immer auf der Binären Schiene hängen. Geht euch das auch so?
Gerade weil man belibig lang werden kann, braucht man doch kein Binärfeld dazu?
Ich meine, Varchar holt sich doch sowieso nur soviele Bytes wie es braucht?
Meines Wissens braucht ein Index auf so ein Feld für jeden Eintrag die maximale definierte Länge, auch wenn der eigentliche Eintrag viel kleiner ist. Wenn du ein indiziertes Feld hast, ist es also nicht klug das maximal groß zu machen.
-
Tach!
Obwohl man bei Varchar jede beliebige Bytezahl benutzen kann, bleibe ich immer auf der Binären Schiene hängen. Geht euch das auch so?
Gerade weil man belibig lang werden kann, braucht man doch kein Binärfeld dazu?Er meinte 2, 4, 8, 16, 32, 64, 128, 256, ...
Ich meine, Varchar holt sich doch sowieso nur soviele Bytes wie es braucht?
Meines Wissens braucht ein Index auf so ein Feld für jeden Eintrag die maximale definierte Länge, auch wenn der eigentliche Eintrag viel kleiner ist.Diesen Satz versteh ich nicht.
Wenn du ein indiziertes Feld hast, ist es also nicht klug das maximal groß zu machen.
Die Maximallänge eines Index ist 1000 Bytes bei MyISAM und 767 Bytes bei InnoDB, das sind dann 333 beziehungsweise 255 Zeichen bei UTF-8-Feldern (und noch etwas weniger bei utf8mb4). Es ist auch nicht in jedem Fall erforderlich, dass der Index über das gesamte Feld geht. Beispielsweise kann man den Index begrenzen, wenn sich die Daten bereits in den ersten x Zeichen/Bytes unterscheiden. Das spart Plattenplatz und ist schneller beim INSERT. Insofern muss man von Fall zu Fall entscheiden, was für diesen klug ist und was nicht.
dedlfix.
-
Meines Wissens braucht ein Index auf so ein Feld für jeden Eintrag die maximale definierte Länge, auch wenn der eigentliche Eintrag viel kleiner ist.
Diesen Satz versteh ich nicht.
Ich habe mal wo aufgeschnappt (allerdings weiß ich nicht mehr für welche DB) dass es so läuft:
Bei einem nvarchar(50) Feld und 3o Datenzeilen werden für den Index 30 x 50 Zeichen benötigt, auch wenn die Felder alle leer sind. Wahrscheinlich wird da für den Index mit festen Feldlängen / Offsets gearbeitet.Von daher wäre es schlecht, einem Feld mal eben 500 Zeichen zu geben weils ja eh nichts kostet und dann darauf einen Index zu setzen, wenn auch 50 Zeichen genügen müssten.
Es ist auch nicht in jedem Fall erforderlich, dass der Index über das gesamte Feld geht.
Sofern man weiß wie es geht :-)
Wieder was gelernt!-
Tach!
Meines Wissens braucht ein Index auf so ein Feld für jeden Eintrag die maximale definierte Länge, auch wenn der eigentliche Eintrag viel kleiner ist.
Diesen Satz versteh ich nicht.
Bei einem nvarchar(50) Feld und 3o Datenzeilen werden für den Index 30 x 50 Zeichen benötigt, auch wenn die Felder alle leer sind. Wahrscheinlich wird da für den Index mit festen Feldlängen / Offsets gearbeitet.Jetzt versteh ich den Satz auch. Und ja, das wird sich auch nicht anders realisieren lassen. Bei einer variablen Feldlänge kann man nicht gezielt auf bestimmte Positionen springen, sondern muss sich immer von vorn durchhangeln, weil nur jedes Element selbst weißt, wie lang es ist und wo das nächste beginnt. Damit fielen zum Beispiel solche Suchmethoden weg, die ein Element in der Mitte anschauen und dann entscheiden, ob sie oberhalb oder unterhalb weitersuchen müssen. Dort dann wieder in die Mitte schauen, usw. usf.
dedlfix.
-
-
-
-
Die Frage, die "ich" hier als erstes stellen würde: Warum ist das Feld *mal wieder* zu klein geworden?
Felder sollten vom Design her entsprechend der aufzunehmenden Werte dimensioniert sein?
Vielleicht solltest du mal unter die Lupe nehmen, wie unterschiedlich die Längen der Daten in diesem Feld sind und warum sie so unterschiedlich sind.
Gruss, Frank
-
Moin Montagsmuffel,
Die Frage, die "ich" hier als erstes stellen würde: Warum ist das Feld *mal wieder* zu klein geworden?
Felder sollten vom Design her entsprechend der aufzunehmenden Werte dimensioniert sein?Weil am Anfang nicht ab zu schätzen war, welche Werte genau in das Feld kommen. Es sollten eigentlich kleine Beschreibungen sein. Jetzt sind es immer noch kleine Beschreibungen, doch wollen die Herrschaften auch HTML in Form von Links in das Feld packen. Und schwups hat sich die Größe verdoppelt.
Als nächstes sind wahrscheinlich mittelgroße Beschreibungen erwünscht. Also im Design kann ich mir keine Vorwürfe machen!Gruß
Architekt
T-Rex-
Als nächstes sind wahrscheinlich mittelgroße Beschreibungen erwünscht.
Für mich wäre das ein Kandidat für maximale Länge.
Probiers aus, knall 1 Mio kurze Einträge rein und schau wie der Speicherbedarf zunimmt. Wenn du merkst dass wirklich nur die benötigte Länge verbraucht wird und du nicht in irgendwelche anderen Problemchen (wie die mit dem Index) laufen kannst, machs doch gleich *groß* genug.
-
-