Moin!

Ich frage mich schon länger, wann man TEXT und wann man VARCHAR-Spalten nimmt - und warum! Klar, was der Unterschied laut Doku in den Datentypen ist, weiß ich auch. Mir geht´s mehr darum wie es hier diskutiert wird:

MySQL Forums :: General :: why to use varchar and not text? hat folgendes geschrieben:

why to use varchar and not text? Posted by: warrior23 () Date: March 12, 2006 05:00PM Hi, I have a simple question: When storing short strings like email adresses or nicknames you usually would use varchar-columns. But why not use text? What disadvantages does text have? Differences are: - trailing-spaces don't get removed in text columns, in varchar-columns they do get removed. I don't see this as an advantage for either data type. - There is no default-value for text column. Okay one disadvantage for the text-datatype, but only if you need a default-value. - for indexes on text-columns you must specify an prefix length. Fair enough, but no disadvantage nor advantage. - you have to be 'careful' using sort or group by on text columns, there you again have to specify a length. Okay. - text columns require 1 (in words: one) byte more space to store than varchar colmuns. Text columns require (string-lenght + 2) bytes storage and varchar columns require (string-length + 1) bytes to store. You would save 1 (one) Megabyte storage every 1.000.000 rows if you use varchar instead of text. I can't really count this as a disadvantage, the difference is just too small. Until now I thought, that when you store short strings in text columns you would lose performance compared to varchar columns. I ran a test and created two tables, each with two rows. One integer auto_increment primary key and one varchar(255) column, the second table had a text column instead of the varchar(255) column. With PHP I inserted 50.000 rows of a 80 char long text into both tables, I ran the test 6 times each. There was hardly any difference, on average the text table was even 0,043 seconds faster than the varchar table. Then I ran a select-test on both tables, each fetching 50.000 rows (select * from test_table and then a 50.000-loop with mysql_fetch_row()), and ran the script 6 times. Only 0,012 seconds difference this time. So, there is no difference in performance and speed. The only disadvantage of text columns is that you can't specify a default value. So why not always use text instead of varchar (except when a default value is required)?

Also, ich bitte um rege Diskussion!

cu
Narses

TEXT ist ein BLOB mit Zeichensatzinfo (in Oracle auch als CLOB bekannt). Ich denke, das sagt alles

-> VARCHAR wird in der Zeile gespeichert, TEXT je nach Storage Engine "woanders" (vgl. MEMO-Felder in DBase4). Das hat ggf. Bedeutung für Zugriffsgeschwindigkeiten. Außerdem werden Indizes da anders gebaut.
Außerdem: TEXT kann länger, VARCHAR2 entspricht sowas wie ShortString und ist dementsprechend auf 1 Byte Länge begrenzt. TEXT kann immerhin 64k. Also allein das ist schon ein Grund: BenBE's berühmten Mega-Beitrag könntest du in einem Varchar gar nicht ablegen

Alte Faustregel: Volltextsuche (Index FULLTEXT) und/oder lange Texte sind ein Zeichen für TEXT, kürzere Texte und/oder BTree-Indizes (für LIKE) sind ein Zeichen für VARCHAR2. CHAR will man niemals.

Was der Mensch da als Test gemacht hat, ist übrigens völlig am Thema vorbei. Das sind knapp 12MB (damit auf ordentlich eingerichteten DBs komplett In-Memory), kein Index und die Abfrage ist ein Full Table Retrieval, das ist kein Performance-Indikator. Da wird nur die Bandbreite mysqld->php getestet.


Alle Angaben ohne Gewähr, your Engine may vary. Aber so hab ichs mal gehört und gelesen...

And in case 64k aren't enough for anyone: There's always LONGTEXT

@Martok: CHAR ist unter Umständen sinnvoll, wenn man z.B. ne In-Memory-Table für Sessions baut, um anhand der SID schnell die UID nachzuschlagen: CHAR(32)+INTEGER(10) = 36 Bytes mit Table Layout static. Darauf nen Binary Tree und du hast Lookup Time O(log(n)) Man spart sich da also durchaus einiges an Memory Management. Aber ja: In den meisten Fällen will man KEIN CHAR, sondern VARCHAR (Ich musste grad länger als ne halbe Minute nachdenken um ein zumindest grundlegend realistisches Szenario für CHAR zu finden).

Okay, zur Frage VARCHAR vs. TEXT: Der vergleicht da grad mal Äpfel mit Birnen. Wenn er das schon vergleicht, dann sollte er wenigstens VARCHAR und TINYTEXT vergleichen. Nur TEXT wäre nämlich MEDIUMTEXT.

Und bzgl. der Nachteile: Wie Martok bereits schrieb: Solang man alles in Memory hat, macht das recht wenig. Sobald man sein IO anstrengen muss für ne Tabelle ist beides tödlich Aber wie das mit Full Table Scans ist, weiß Narses glaube am besten

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Soweit ich weis ist Char generell bei Werten sinnvoll die immer die selbe Länge haben, z.B. eine id von 30 Zeichen etc.
Das es unsinn ist wenn man einen Char(30) hat und nur 2 Zeichen braucht ist natürlich offensichtlich. ^^
Die Doku hier gibt mir soweit recht.

dev.mysql.com/doc/re...e/static-format.html

Moin!

Danke euch allen für die Hinweise!

Martok hat folgendes geschrieben :

VARCHAR wird in der Zeile gespeichert, TEXT je nach Storage Engine "woanders" (vgl. MEMO-Felder in DBase4).

Das hatte ich vermutet, aber nirgendwo in der MySQL-Doku explizit gefunden. Das erklärt schon einiges.

Martok hat folgendes geschrieben :

Alte Faustregel: Volltextsuche (Index FULLTEXT) und/oder lange Texte sind ein Zeichen für TEXT, kürzere Texte und/oder BTree-Indizes (für LIKE) sind ein Zeichen für VARCHAR2. CHAR will man niemals.

Du verwirrst mich etwas mit VARCHAR2, was ist das? In der MySQL-Doku kann ich´s nicht finden...

Martok hat folgendes geschrieben :

Was der Mensch da als Test gemacht hat, ist übrigens völlig am Thema vorbei. Das sind knapp 12MB (damit auf ordentlich eingerichteten DBs komplett In-Memory), kein Index und die Abfrage ist ein Full Table Retrieval, das ist kein Performance-Indikator. Da wird nur die Bandbreite mysqld->php getestet.

Ich hatte es auch vermutet, aber auch hier nochmal Danke für´s Klarstellen.

cu
Narses

Upps, Sorry.

VARCHAR2 heißt das bei Oracle.