Hallo allemaal,

Een kort vraagje.

Als je een VARCHAR veld in je database hebt van bijv. 50 tekens, maakt het dan voor het geheugen of bestandsgrootte van de database iets uit of er wel of niet een waarde in dat veld staat?

Waarom ik dit graag wil weten ... ik wil ergens een hash gebruiken om een rij in een database te kunnen identificeren, maar dat hoeft maar 1x te gebeuren. Stel ik heb 1.000 rijen, dan heb ik dus ook 1.000 hashes. Aangezien ik de hash maar eenmalig nodig heb, zou ik het veld daarna kunnen leegmaken. Wordt daarmee de database dan ook kleiner? Of reserveert die VARCHAR(50) altijd dezelfde ruimte, ongeacht of je er wel of niet iets invult?
Indien je de hash maar voor één ding gebruikt (bijvoorbeeld, ik noem maar wat, voor een activatiecode voor een gebruikersaccount) en hier al een tabel voor is (bijvoorbeeld een tabel users, gebruikers whatever) dan zou ik die hash gewoon opnemen in die tabel en als je de hash niet meer nodig hebt die kolom NULL maken (zijn NULLable kolommen trouwens voor diskruimte efficiënter of maakt dit niet uit?).

De hash heeft in dat geval namelijk buiten die tabel niet zoveel bestaansrecht en zoals hierboven staat kun je (mogelijk meer) winst pakken op andere plaatsen.

Je zou bijvoorbeeld via een cron alle tabellen bij tijd en wijlen OPTIMIZEn, dat kan, in ieder geval voor snelheid, al wat uitmaken.

Oh, en als je uitsluitend van InnoDB gebruik maakt maakten bepaalde instellingen nogal veel uit. In mijn inmiddels wat gedateerde WAMP-opstelling zag ik dat mijn MySQL-(hulp)bestanden alleen maar groter werden terwijl ik geen data aan het toevoegen was maar zelfs aan het verwijderen / OPTIMIZEn was. Het heeft weinig zin om deze instellingen te wijzigen als de database al actief is maar je zou kunnen proberen om aparte hulpbestanden aan te houden per tabel middels de flag innodb_file_per_table. En daarnaast zou je andere settings kunnen tweaken zoals expire_logs_days (voor een rotatie van de bin-files) en innodb_log_file_size en innodb_buffer_pool_size. De simpelste manier om je database met deze nieuwe instellingen te laten werken lijkt mij het opnieuw opzetten hiervan (dump, drop, (edit: en rond dit punt even de instellingen wijzigen uiteraard :p) import). Het is wat moeilijker om dit on-the-fly te doen.
Hebben eigenlijk alle database types last van dit soort problemen?

Kan ik in plaats van InnoDB beter voor iets anders kiezen dan?
> Hebben eigenlijk alle database types last van dit soort problemen?
Geen idee eigenlijk.

> Kan ik in plaats van InnoDB beter voor iets anders kiezen dan?
Nou nee voor zo gauw ik weet niet, want InnoDB gebruik je voor echte relationele databases (foreign keys, transacties etc.).
Hmmm, oké thanks. Het blijft een vreemde materie die databases :-s

Reageren