6
Unterschied zwischen Char und Varchar? Wieso benötige ich überhaupt noch Char?
Hallo Community,
ich habe eine kurze Frage zu zwei Datentypen. Und zwar handelt es sich um Char und Varchar. Ich habe ebend nachgelesen, das Varchar die Länge anpasst bis zur maximal angegbenen Länge. Char benötigt jedoch immer die gleiche Speichergröße, da der Leerraum mit Leerzeichen gefüllt wird. Jetzt sehe ich aber kein Vorteil darin Char zu nehmen, wenn ich mit Varchar sowieso auf das gleiche Ergebnis komme (nagut, wir benötigen für die gleiche Menge pro Datensatz 1 Byte mehr) und dabei Platz sparen kann, weil der Datentyp sich nur soviel holt, wie er benötigt.
Kann mir jemand daher sagen, warum es den Char Datentyp überhaupt noch gibt? Für mich klingt das so, als wen Varchar ein neuere Erfindung wäre und Char bald ablösen könnte, oder?
Vielen Dank für euere unterstützung.
spekcles
Vielen Dank für euere unterstützung.
spekcles
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 139287
Url: https://administrator.de/contentid/139287
Printed on: April 19, 2024 at 10:04 o'clock
6 Comments
Latest comment
Danke Dani,
aufgrund dieser Tabelle ist mir auch erst die Frage gekommen
VARCAHR nimmt sich den Platz den es braucht bzw. bis zur maixmalen Länge. Das CHAR deklariere ich aber fest, sodass ich immer eine konstante Speicherbedarf habe.
Warum sollte ich also mehr Speicherbedarf als notwendig nehmen?
Wenn ich ein ein ein Varchar eine maximale länge von 5 gebe, dann haushalte ich doch besser mit meinem Speicher, weil wenn ich nur 3 brauche nimmt er sich nur drei. Bei Char nimmt er immer 5.
aufgrund dieser Tabelle ist mir auch erst die Frage gekommen
VARCAHR nimmt sich den Platz den es braucht bzw. bis zur maixmalen Länge. Das CHAR deklariere ich aber fest, sodass ich immer eine konstante Speicherbedarf habe.
Warum sollte ich also mehr Speicherbedarf als notwendig nehmen?
Wenn ich ein ein ein Varchar eine maximale länge von 5 gebe, dann haushalte ich doch besser mit meinem Speicher, weil wenn ich nur 3 brauche nimmt er sich nur drei. Bei Char nimmt er immer 5.
Hallo,
ich gehe davon aus, dass char-Werte effizienter verarbeitet werden können, da ihre Länge von vorneherein bekannt ist. Sollen hier 100 Werte selektiert werden, so müssen nur 100 * x Byte gelesen werden. Bei varchar muss erst 100 * 1 Byte gelesen, dieses ausgewertet und dann 100 * unterschiedlich lange Ketten gelesen werden. Daneben kenne ich die genauen Zugriffs-/Organistationsstrukturen der verschiedenen DBMS nicht, aber das könnte sogar dann zum Tragen kommen, wenn ich ein hinter dem varchar gespeicherten Wert auslesen muss: Wenn ich innerhalb einer Seite nur Felder mit immer gleicher Länge habe, so kann ich für jedes Feld den Offset errechnen, und direkt darauf zugreifen. Wenn aber die Länge der Felder undefiniert ist, so muss ich mich von vorne bis zum gewünschten "durchhangeln". Dieser Effekt wäre sogar noch sehr viel größer als der erstgenannte und würde wohl zu einem enormen Effizienzgewinn von char gegenüber varchar führen. Weiterhin könnten sich statische Feldlängen bezüglich der Fragmentierung der DB als vorteilhaft erweisen.
Gruß
Filipp
ich gehe davon aus, dass char-Werte effizienter verarbeitet werden können, da ihre Länge von vorneherein bekannt ist. Sollen hier 100 Werte selektiert werden, so müssen nur 100 * x Byte gelesen werden. Bei varchar muss erst 100 * 1 Byte gelesen, dieses ausgewertet und dann 100 * unterschiedlich lange Ketten gelesen werden. Daneben kenne ich die genauen Zugriffs-/Organistationsstrukturen der verschiedenen DBMS nicht, aber das könnte sogar dann zum Tragen kommen, wenn ich ein hinter dem varchar gespeicherten Wert auslesen muss: Wenn ich innerhalb einer Seite nur Felder mit immer gleicher Länge habe, so kann ich für jedes Feld den Offset errechnen, und direkt darauf zugreifen. Wenn aber die Länge der Felder undefiniert ist, so muss ich mich von vorne bis zum gewünschten "durchhangeln". Dieser Effekt wäre sogar noch sehr viel größer als der erstgenannte und würde wohl zu einem enormen Effizienzgewinn von char gegenüber varchar führen. Weiterhin könnten sich statische Feldlängen bezüglich der Fragmentierung der DB als vorteilhaft erweisen.
Gruß
Filipp
Außerdem hast Du mit VChar ein fragmentierungsproblem. Wenn Du bei allen Datensätzen diesem Wert ein Zeichen hinzufügst müssen ja alle Datensätze, bzw. das Feld, komplett neu geschrieben werden, da der Platz nicht ausrecht.
Stefan
Stefan
Hallo,
Gruß
Filipp
Wenn Du bei allen Datensätzen diesem Wert ein Zeichen
hinzufügst müssen ja alle Datensätze, bzw. das Feld, komplett neu geschrieben werden, da der Platz nicht
ausrecht.
das wiederum macht zumindest MS SQL sowieso so: De facto gibt es kein UPDATE, sondern dies ist nur eine Kapselung für ein DELETE und INSERT (sprich: Bei einer Aktualisierung eines Feldes eines Datensatzes wird der ganze Datensatz neu geschrieben). Wahrscheinlich genau deswegen... Und ich gehe davon aus, dass das bei anderen DBMS genauso ist. Aber man kann später in den dann nicht genutzten Platz einen neuen Datensatz einfügen, wenn alle Datensätze gleich lang sind.hinzufügst müssen ja alle Datensätze, bzw. das Feld, komplett neu geschrieben werden, da der Platz nicht
ausrecht.
Gruß
Filipp
Der Unterschied zwischen Char und Varchar im kleinen ist unerheblich, und Varchar ist da sicher flexibler und bequemer. Sobald die DBs etwas grösser werden ist allerdings Char wesentlich(!) performanter als Varchar (sowohl im Bereich reine Abfrage als auch Vergleiche u.ä.), und wie schon von meinen Vorgängern geschrieben gibts auch ein kleines Problem mit Frakturierung bei Varchar. Wenn man von vorneherein weiss welche Länge der Eintrag haben wird (Personalnummern etc) ist Char immer zu bevorzugen.
