Bør jeg angive lavere længde af Varchar, hvis jeg kun bruger 10?

Eller er det bare "god kutyme", at sætte felterne til det de reelt må indeholde?

Du bør altid - som udgangspunkt - vælge den datatype (og størrelse) der bedst passer til de data, du regner med at lægge i feltet.

På varchars tvivler jeg på du vil kunne mærke den store forskel om det er en varchar(255) eller varchar(10), men hvis du vil have performance, og tror 10 tegn er nok, vil du med fordel sandsynligvis kunne benytte en char(10).

For "sandkasser" er det meget praktisk at have plads til at boltre sig (med varchar(255)), men hvis det formål feltet tjener, aldrig vil komme over en given størrelse 10, 50 eller 100 tegn, så er der ingen grund til at risikere at forvirre sig selv (eller andre) ved at gøre det meget større, end det for mål, som feltet tjener.

Det har en praktisk idet der afsættes plads til det antal tegn du angiver. Derfor går jeg ud fra at der vil være mindre spildplads, hvis du angiver hvad du har brug for og ikke bare 255.

Et af de bedre eksempler jeg kender, var et dato-felt, som var blevet defineret som en char(10) - det passede jo lige til en "YYYY-MM-DD" string.

Fedt nok - men hvorfor så ikke bare bruge en dato (og dermed have adgang til dato-funktionerne i SQL)? - Hvis man kan være sikker på, at der altid skal ligge en dato (eller feltet er tomt), så er der ikke nogen grund til ikke at benytte det "bedst egnede felt" - og det er sandsynligvis også det mest effektive på lang sigt.

Der er ingen plads eller hastigheds-forsklle ved at bruge VARCHAR(255) fremfor
VARCHAR(50), da VARCHAR kun bruger den faktiske plads ikke max. plads.

Dit valg skal derfor baseres på hvorvidt
du ønsker at få en fejl hvis der indtastes for lange data fordi
det indikerer enten en bruger fejl eller en applikations fejl. Og
hvorvidt du er sikker på at nuværende begrænsning også vil gælde i fremtiden.

Med varchar bliver der ikke afsat plads til det antal tegn man angiver, men
til det antal tegn der faktisk bliver brugt.

Der er ingen forskel i udførelse på nogen måde i at skrive varchar(10) isf
varchar(255).

Der skal mere beregningsarbejde til at finde poster der indeholder
variabellængde-felter end dem der fx kun indholder char - men til gengæld
fylder de sidste mere.

dsj:

Nej. Sandsynligvis ikke.

"Support for a true VARCHAR type; a VARCHAR column starts with a length stored in 2 bytes."
- http://www.mysql.com/doc/en/MyISAM.html

"All string columns are dynamic (except those with a length less than 4)."
"Usually takes much less disk space than fixed-length tables."
- http://www.mysql.com/doc/en/Dynamic_format.html

Med en standard installation af mysql, vil en varchar(50) og en varchar(100) fylde det samme, hvis de skal gemme en tekst på f.eks. 25 tegn.

Mange tak for alle jeres svar.
Jeg har nu optimeret min DB. Så har jeg i hvertfald lidt mere styr over tingene. Det er også rart at vide, at det kun er antallet af tegn, der bestemmer størrelsen.

Smid svar, folkens.
(fx. dig, Erik)