Dit hangt volledig af van de DBMS-engine die wordt gebruikt. SQL zelf bepaalt niet hoe dingen fysiek worden opgeslagen, alleen hoe ze logisch worden gezien.
Uw DBMS kan bijvoorbeeld ruimte in de rij toewijzen voor de maximale grootte, plus enkele extra bytes om de lengte op te slaan. In dat geval zou er een groot verschil zijn tussen varchar(10) en varchar(1000) aangezien je nogal wat ruimte per rij zou verspillen.
Als alternatief kan het een bufferpool gebruiken voor de varchar gegevens en sla alleen de lengte en het "startadres" van de bufferpool op in de rij. In dat geval zou elke afzonderlijke rij informatie van dezelfde grootte opslaan voor een varchar kolom ongeacht de grootte, maar er zou een extra stap zijn om de feitelijke gegevens in die kolom te extraheren (volgens de link naar de bufferpool).
De reden waarom je een varchar . gebruikt is precies waarom het varchar heet . Hiermee kunt u gegevenselementen van variabele grootte opslaan. Meestal char(10) geeft je tien tekens, wat er ook gebeurt, vul het met spaties als je iets korters invoegt. Je kunt achterliggende spaties wegknippen terwijl je het uitpakt, maar dat zal niet zo goed werken als de gegevens die je wilt opslaan eigenlijk "hello " zijn , met een volgspatie die u wilt behouden.
Een fatsoenlijke DBMS-engine kan besluiten om een afweging te maken, afhankelijk van de maximale grootte van de varchar kolom. Voor korte, zou het het gewoon inline in de rij kunnen opslaan en de extra bytes voor de grootte verbruiken.
Langere varchar kolommen kunnen worden "uitbesteed" aan een aparte bufferpool om ervoor te zorgen dat het lezen van rijen efficiënt blijft (tenminste totdat u nodig de grote varchar kolom in ieder geval).
Wat u moet doen, is de vraag voor uw specifieke DBMS opnieuw stellen om een gerichter antwoord te krijgen.
Of, eerlijk gezegd, ontwikkel uw database om alleen de maximale grootte op te slaan. Als je weet dat het 10 is, dan varchar(1000) is een verspilling. Als u in de toekomst de kolom moet vergroten, dat is de tijd om het te doen, in plaats van nu (zie YAGNI
).
Voor MySQL kijk je naar Chapter 14 Storage Engines
van de online documentatie.
Het omvat de verschillende storage-engines (zoals InnoDB en MyISAM) die MySQL gebruikt en als je diep genoeg kijkt, kun je zien hoe de informatie fysiek is opgeslagen.
In MyISAM kan bijvoorbeeld de aanwezigheid van gegevens met variabele lengte in een tabel (varchar inbegrepen) betekent meestal dynamische tabellen
. Dit volgt een schema dat ruwweg analoog is aan het bufferpoolconcept dat ik hierboven noemde, met als voordeel dat er minder ruimte wordt verspild aan kolommen met variabele afmetingen en het nadeel dat rijen gefragmenteerd kunnen raken.
Het andere opslagformaat (met korting op gecomprimeerd formaat omdat het alleen echt wordt gebruikt voor alleen-lezen tabellen) is de statische één , waar gegevens worden opgeslagen in een enkele fysieke rij.
Informatie over de fysieke structuren van InnoDB is te vinden hier . Afhankelijk van of je het Antelope- of Barracuda-bestandsformaat gebruikt, krijg je de situatie "alle informatie is een fysieke rij" of "bufferpool", vergelijkbaar met het MyISAM-onderscheid tussen dynamisch en statisch.