Varchar of BLOB in MySQL

[Verwijderd]

Wat is de invloed op de grote van de database als je kiest tussen een varchar veld of een BLOB veld in een MYSQL database?
Heeft deze keuze ook invloed op de snelheid van de database?

varchar lengtes heeft dat ook invleod op de snelheid?

[ACM]

Je bedoelt dan dus TEXT vs Varchar?

Bij mijn weten worden text-velden niet inline met de gegevens opgeslagen en de (var)char-velden wel.
Zul je in de mysql documentatie moeten nazoeken of dat inderdaad zo is.

Of het een merkbare invloed op de snelheid heeft, misschien een klein beetje. Vooral waarsch als je de gegevens allemaal ophaalt (of iig de text-velden ook meeneemt).

Lengtes van varchars hebben nauwelijks invloed op de snelheid gok ik, maar het is natuurlijk wel zo dat je hem niet onnodig lang moet kiezen. Sommige db's vinden namelijk dat een varchar van lengte 20 ook 20 bytes neemt, ondanks dat je er maar 10 chars in stopt.
Dit laatste lijkt me trouwens een van de belangrijkere verschillen tussen text en varchar, maar ik weet niet of dit ook voor mysql geldt.

Voor postgresql iig niet (je kan varchars van 2GB definieren en dan neemt echt niet elk record 2GB in ).

[whoami]

grr.... Ik had hier reeds een reply gepost en ik kreeg een error...

Ik denk niet dat je op een TEXT of BLOB veld een index kunt plaatsen, en je kunt op een TEXT veld ook geen LIKE doen afaik.
TEXT gebruik je enkel als je grote lappen text wilt opslaan of als je niet weet hoe veel tekst er zal komen. De replies in een topic op een forum kun je bv als TEXT opslaan.
Als je gewone gegevens zoals namen, adressen etc.... wilt opslaan, gebruik je best een varchar.

[ACM]

whoami schreef op 10 oktober 2002 @ 14:12:
Ik denk niet dat je op een TEXT of BLOB veld een index kunt plaatsen, en je kunt op een TEXT veld ook geen LIKE doen afaik.

Kan beide prima.
Tenminste, het kan maar zeker niet in elke database, postgresql en mysql iig wel
Like kan sowieso, zelfs bij blob (waar je dat voor zou willen doen, vraag het mij niet)

En indices op TEXT en BLOB kan ook, ook daar ontgaat het nut me een beetje van.
Wel is het zo dat er dan bijv restricties aan de lengte van het text-veld gesteld kunnen worden (oudere versies van postgres deden dat iig).

TEXT gebruik je enkel als je grote lappen text wilt opslaan of als je niet weet hoe veel tekst er zal komen. De replies in een topic op een forum kun je bv als TEXT opslaan.
Als je gewone gegevens zoals namen, adressen etc.... wilt opslaan, gebruik je best een varchar.

Deze richtlijn zou ik daarom iig wel aanhouden

[whoami]

[nohtml]

ACM schreef op 10 oktober 2002 @ 14:15:
[nohtml]
[...]

Kan beide prima.
Tenminste, het kan maar zeker niet in elke database, postgresql en mysql iig wel
Like kan sowieso, zelfs bij blob (waar je dat voor zou willen doen, vraag het mij niet)

En indices op TEXT en BLOB kan ook, ook daar ontgaat het nut me een beetje van.
Wel is het zo dat er dan bijv restricties aan de lengte van het text-veld gesteld kunnen worden (oudere versies van postgres deden dat iig).

Hmm vreemd, het nut van een index op een TEXT veld ontgaat me ook. (en het nut van een like op een tekstveld eigenlijk ook).
Ik heb ooit een project gedaan met een Informix databank, en in die versie van Informix kon je geen index op een text leggen als ik me nog goed herinner (en een like ging ook niet).
Maar goed, het is idd databank-afhankelijk.

[ACM]

whoami schreef op 10 oktober 2002 @ 14:19:
(en het nut van een like op een tekstveld eigenlijk ook).

Mja, dat is dan natuurlijk de banaalste vorm van een search-engine

Als je maar 20 tekstjes in je DB hebt (ok, moeten ze niet 16MB ofzo zijn) is het veel makkelijker gewoon even met LIKE erdoorheen te gaan dan moeilijk te doen met allerlei andere oplossingen.

[Verwijderd]

Even een andere vraag m.b.t. text velden: kun je deze ook als geheel als primary key gebruiken binnen mysql? Ik heb namelijk een erg lange string (400 karakters) en die mag maar eenmaal voorkomen in de db.
De performance van de DB maakt niet uit.

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 14:26:
Even een andere vraag m.b.t. text velden: kun je deze ook als geheel als primary key gebruiken binnen mysql? Ik heb namelijk een erg lange string (400 karakters) en die mag maar eenmaal voorkomen in de db.
De performance van de DB maakt niet uit.

Ehm, leg er dan gewoon een unique constraint op ofzo...
Stel dat je die tabel later met een andere tabel gaat gaan joinen.... Dan heb je een foreign key in die andere tabel van 400 karakters, en dat wil je echt niet...

Er zijn geen mooiere Primary keys als nummertjes.

[Verwijderd]

De performance van de DB maakt niet uit.

Confussios sais: "Performance is never a problem, a lack of performance is!"

[wustenveld]

ACM schreef op 10 oktober 2002 @ 14:10:
Sommige db's vinden namelijk dat een varchar van lengte 20 ook 20 bytes neemt, ondanks dat je er maar 10 chars in stopt.
Dit laatste lijkt me trouwens een van de belangrijkere verschillen tussen text en varchar, maar ik weet niet of dit ook voor mysql geldt.

Voor postgresql iig niet (je kan varchars van 2GB definieren en dan neemt echt niet elk record 2GB in ).

Ik dacht altijd dat het juist een text veld was die standaard alle ruimte inneemt. Dus een textveld van 20 neemt 20 bytes in beslag. En een varchar van 20 neemt 0 bytes in als er niks in staat, en 10 bytes als er 10 tekens in staan.

Althans dat had ik een keer gelezen in een mySQL handleiding

[Verwijderd]

Heeft een varchar niet een maximale grootte van 256 characters? En een blob/text (is volgens mij synoniem) in principe onbeperkt? Overigens staat dit soort info allemaal in de documentatie op mysql.com.

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 15:26:
Heeft een varchar niet een maximale grootte van 256 characters? En een blob/text (is volgens mij synoniem) in principe onbeperkt? Overigens staat dit soort info allemaal in de documentatie op mysql.com.

Een Text is idd onbeperkt. Het DBMS gaat afaik zelf space gaan alloceren wanneer dat nodig blijkt.
Een varchar is niet beperkt tot 256 characters (maar ook dat zal wel afhankelijk zijn van dbms tot dbms). Het is bv in SQL Server perfect mogelijk om een varchar veld van 2048 characters te hebben (en meer zal ook wel lukken).
* whoami is even te lui om het te gaan opzoeken.

[Verwijderd]

In het kader van RTFM:

In most respects, you can regard a TEXT column as a VARCHAR column that can be as big as you like. Similarly, you can regard a BLOB column as a VARCHAR BINARY column. The differences are:

* You can have indexes on BLOB and TEXT columns with MySQL Version 3.23.2 and newer. Older versions of MySQL did not support this.
* There is no trailing-space removal for BLOB and TEXT columns when values are stored, as there is for VARCHAR columns.
* BLOB and TEXT columns cannot have DEFAULT values.

Zie handleiding op mysql.com dus!

[Verwijderd]

_kuch_ _kuch_ ff me gelijk halen =)

Values in VARCHAR columns are variable-length strings. You can declare a VARCHAR column to be any length between 1 and 255, just as for CHAR columns.

[whoami]

Verwijderd schreef op 10 oktober 2002 @ 15:31:
_kuch_ _kuch_ ff me gelijk halen =)

Values in VARCHAR columns are variable-length strings. You can declare a VARCHAR column to be any length between 1 and 255, just as for CHAR columns.

Databank gebonden dus, want in SQL Server:

varchar[(n)]

Variable-length non-Unicode character data with length of n bytes. n must be a value from 1 through 8,000. Storage size is the actual length in bytes of the data entered, not n bytes. The data entered can be 0 characters in length. The SQL-92 synonyms for varchar are char varying or character varying.

In Informix is het meer dan 255, maar minder dan 8000 dacht ik....

Zo zie je maar dat MySQL de naam DBMS niet waardig is.

[ACM]

wustenveld schreef op 10 oktober 2002 @ 15:22:
Ik dacht altijd dat het juist een text veld was die standaard alle ruimte inneemt. Dus een textveld van 20 neemt 20 bytes in beslag. En een varchar van 20 neemt 0 bytes in als er niks in staat, en 10 bytes als er 10 tekens in staan.

Althans dat had ik een keer gelezen in een mySQL handleiding

Dat zou wat wezen zeg.

Textvelden van 20 bestaan trouwens niet
Maar GoT werkt met textvelden van 64KB en _gelukkig_ nemen niet alle messages 64KB in Dan zou de database wel even een *kuch* stukje groter zijn... (gemiddelde is ergens in de buurt van 1a2KB ofzo).

Juist een textveld/blob is volledig variabel in lengte (kwa opslag).
Varchars in bijv interbase zijn niet variabel in lengte (kwa opslag) en het enige verschil met chars is dat er geen spaties aan toegevoegd worden bij de output.

Verwijderd schreef op 10 oktober 2002 @ 15:26:
Heeft een varchar niet een maximale grootte van 256 characters? En een blob/text (is volgens mij synoniem) in principe onbeperkt? Overigens staat dit soort info allemaal in de documentatie op mysql.com.

Nee, dat geldt alleen voor mysql.
En mysql is gelijk de enige die een dusdanig beperkte lengte kent (bij mijn weten Msql vast ook wel).

Veel databases zitten rond de 8000 of nog groter (64000 bijv).
Postgresql kan zelfs een varchar (MAXINT) aan, ergens rond de 2G dus.

whoami schreef op 10 oktober 2002 @ 15:28:
Een Text is idd onbeperkt. Het DBMS gaat afaik zelf space gaan alloceren wanneer dat nodig blijkt.

Dat zal in principe voor een varchar ook moeten, maar dat hangt dus af van hoe en wat de implementatie van dat DBMS doet.

Verwijderd schreef op 10 oktober 2002 @ 15:28:
In het kader van RTFM:

In most respects, you can regard a TEXT column as a VARCHAR column that can be as big as you like. Similarly, you can regard a BLOB column as a VARCHAR BINARY column. The differences are:

* You can have indexes on BLOB and TEXT columns with MySQL Version 3.23.2 and newer. Older versions of MySQL did not support this.
* There is no trailing-space removal for BLOB and TEXT columns when values are stored, as there is for VARCHAR columns.
* BLOB and TEXT columns cannot have DEFAULT values.

Zie handleiding op mysql.com dus!

Wat voor mysql geldt geldt niet perse voor anderen. Ik kan zo snel geen zinvolle reden verzinnen voor een index op een text-veld, maar je zou hem idd als primary key kunnen gebruiken.
Blob en Text hebben trouwens wel degelijk default waarde bij mysql, die vult _altijd_ "" of NULL in als je de kolom niet opgeeft

Verwijderd schreef op 10 oktober 2002 @ 15:31:
_kuch_ _kuch_ ff me gelijk halen =)

Values in VARCHAR columns are variable-length strings. You can declare a VARCHAR column to be any length between 1 and 255, just as for CHAR columns.

Geldt dus alleen voor mysql:

SQL defines two primary character types: character(n) and character varying(n), where n is a positive integer. Both of these types can store strings up to n characters in length. An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length. (This somewhat bizarre exception is required by the SQL standard.) If the string to be stored is shorter than the declared length, values of type character will be space-padded; values of type character varying will simply store the shorter string.

Note: Prior to PostgreSQL 7.2, strings that were too long were silently truncated, no error was raised.

The notations char(n) and varchar(n) are aliases for character(n) and character varying(n), respectively. character without length specifier is equivalent to character(1); if character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

In addition, PostgreSQL supports the more general text type, which stores strings of any length. Unlike character varying, text does not require an explicit declared upper limit on the size of the string. Although the type text is not in the SQL standard, many other RDBMS packages have it as well.

The storage requirement for data of these types is 4 bytes plus the actual string, and in case of character plus the padding. Long strings will be compressed by the system automatically, so the physical requirement on disk may be less. In any case, the longest possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data type declaration is less than that. It wouldn't be very useful to change this because with multibyte character encodings the number of characters and bytes can be quite different anyway. If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit.)

Tip: There are no performance differences between these three types, apart from the increased storage size when using the blank-padded type.

Bron: http://www.postgresql.org...p?datatype-character.html