[SQL] Verschil tussen attribuutwaarde 'Char' en 'Varchar'

[killingdjef]

ik las ergens dat er beter een "varchar" dan 'char' gebruikt kan worden omdat dit minder data in beslag neemt? Kan iemand dit confirmen?

Het zou namelijk zo zijn dat een varchar de ruimte reserveerd maar alleen inbeslag neemt als er tekens staan en dat bij char alles gereserveerd wordt.

Indien dit waar is, wat is dan het nut van beide? Lijkt mij dat je je database zo snel en efficient mogelijk wilt maken. Dan is de varchar het best?

alvast bedankt

[whoami]

Dat klopt.

Als je een veld hebt dat als data-type char(10) heeft, en je stopt er een naam in van vier characters, dan zullen die 4 characters ge-padded worden met spaties, en zullen alle 10 de characters dus ingenomen worden.
Een varchar doet dit niet.

[GVR]

En dat wilde ik ook gaan zeggen

[Sybr_E-N]

Hier staat het allemaal uitgelegd in de documentantie. En nog een stukje over zo klein mogelijke data in het algemeen.

edit:
^^ stupid

[ Voor 43% gewijzigd door Sybr_E-N op 03-03-2005 20:33 . Reden: sloooom ]

[ripexx]

Sybr_E-N schreef op donderdag 03 maart 2005 @ 20:32:
Hier staat het allemaal uitgelegd in de documentantie. En nog een stukje over zo klein mogelijke data in het algemeen.

edit:
^^ stupid

Hmm, nou staat MySQL nou niet echt goed bekend om het gebruik van het juiste datatype

quote: http://vulcanus.its.tudelft.nl/acm/got/antimysql.php

When I define a char(32) (md5-strings anyone) field, I really don't mean varchar(32) (MySQL automatically changes all char(X >4) to varchar(X)).

Bovenstaande komt van een stukje van ACM

Als je kijkt naar het voorbeeld van ACM en je zou dus verschillende MD5 hashes opslaan weet je zeker dat de string altijd 32 karakters heeft. Terwijl een email adres dit niet heeft. Echt een ramp zal het niet zijn, tenzij je echt alleen maar CHAR(255) colums gaat aanmaken. Je zal hoogstens wat teveel dataverbruiken. Maar dat is tegenwoordig toch veel minder een issue.

[killingdjef]

Interessant!
Na de bovenstaande links gelezen te hebben en de MySQL site nog wat verder doorgeplozen(gepluist? ) te hebben vraag ik mij nu in zijn algemeenheid wel eigelijk af hoe je een database zo snel mogelijk kan maken want volgens de comments die ik op de site las maakt het wel degelijk enorm uit.

Ik ben er nu dus achter gekomen dat een varchar beter is, en een small/medint ook stukken scheelt op grotere schaal. Aangezien mijn database alleen werkt met ints en strings vraag ik mij hiernaast nog af of tablesize veel uitmaakt.

Er stond dat de grote van een table veel uit maakt, stel dus dat je een table hebt met 25 attributen ongeveer. Is het dan belangrijk om deze onder te verdelen in 5 tabellen van 5 o.i.d.? Persoonlijk lijkt het mij dan een tikkeltje meer onoverzichtelijk worden maar als het veel in performanche scheelt, waarom niet?

N.B. Ik ga er dus van uit dat er, laten we een leuk getal nemen, 30,000 records zijn en iedere record heeft 3 attributen die een varchar(300) bezit.

[TheekAzzaBreek]

Als je strings een vaste lengte hebben (valutacodes bij voorbeeld) is een char iets efficienter. Een varchar heeft doorgaans onderhuids nog een paar bytes nodig om aan te geven hoeveel data er in staat. Verwerking van een varchar is ook iets trager, omdat die extra bytes gezet / uitgelezen worden, en daar is iets als substr() of length() voor nodig.

Allemaal erg theoretisch, hoor. Als je geen database van minstens tientallen GBs gaat maken is het eigenlijk niet de moeite waard om over na te denken, gebruik dan gewoon varchar.

[TheekAzzaBreek]

Er stond dat de grote van een table veel uit maakt, stel dus dat je een table hebt met 25 attributen ongeveer. Is het dan belangrijk om deze onder te verdelen in 5 tabellen van 5 o.i.d.? Persoonlijk lijkt het mij dan een tikkeltje meer onoverzichtelijk worden maar als het veel in performanche scheelt, waarom niet?

Echte DB tuning is heel specifiek voor een database (~versie zelfs), en ik weet niks van MySql. Maar met boerenverstand kom je een heel eind. Als je zo'n tabel met veel kolommen gaat opsplitsen, maar je hebt al die kolommen nodig, heeft opsplitsen alleen maar negatief effect. Je moet de data blokken (hoe heet dat in MySql?) toch ophalen, maar je moet 4 keer extra een index in om ze te vinden.

Met 30k rijen zou ik me er echt niet druk over maken, dat is toch peanuts voor een beetje DB engine. Zorg voor een gezonde index strategie, en check dat je queries ze gebruiken zoals je bedacht had. Veel nuttiger tijdsbesteding dan dit soort exotica.

[whoami]

De meeste snelheidswinst ga je niet halen door voor een char of een varchar te kiezen; maar bekom je door een goed (genormaliseerd) datamodel te ontwikkelen die aan alle functionele eisen van jouw probleem voldoet.
Zoals hierboven al gezegd wordt, is het ook belangrijk om de goede indexen te bepalen en te leggen, en om deze dan ook te onderhouden.

[Verwijderd]

gaat dit over MySQL? Grappig, want in Oracle heb je dat onderscheid ook.

[whoami]

Verwijderd schreef op vrijdag 04 maart 2005 @ 11:33:
gaat dit over MySQL? Grappig, want in Oracle heb je dat onderscheid ook.

In vrijwel iedere DB heb je dat onderscheid.

[Verwijderd]

Bij strings van een variabele lengte kosten chars meer ruimte, en kosten varchars meer tijd wanneer er een index op dat veld is gedefinieerd. (Niet zozeer bij het gebruik van zo'n index, maar wel bij inserts en updates).
Is er geen index nodig? dan zijn varchars 't handigst.
Wel een index? dan is 't afwegen of die extra ruimte opweegt tegen het feit dat de DB meer moeite moet doen om de index te onderhouden.

In de praktijk kies ik voor bv. productcodes, etc. altijd voor char, en voor dingen als achternaam, plaatsnaam, etc. voor varchar. Maar in een andere situatie is dat misschien helemaal niet zo slim, wanneer er veel op plaatsnaam gezocht wordt bijvoorbeeld.

[stp_4]

Verwijderd schreef op vrijdag 04 maart 2005 @ 12:15:
Bij strings van een variabele lengte kosten chars meer ruimte, en kosten varchars meer tijd wanneer er een index op dat veld is gedefinieerd. (Niet zozeer bij het gebruik van zo'n index, maar wel bij inserts en updates).

Over hoeveel (extra) tijd hebben we het dan in het geval van varchars?

[Verwijderd]

Bij een enkele insert of update is 't nauwelijks merkbaar, maar bij bv. replicatie van 10.000 records kan het verschil dramatisch zijn. Denk dan in de orde van 100 tot 500% verschil in tijd, afhankelijk van hoeveel varchar velden geindiceerd moeten worden.