Google+ Followers

dinsdag 6 december 2011

Ontwerp tipjes, deel 14: kolomnamen.

Kolomnamen moeten beschijvend zijn, ze moeten aangeven wat voor soort data er in de kolom zit en waar die data voor gebruikt dient te worden.

Dat betekent meteen al een schop tegen mijn persoonlijke irritatie nummer één, de 'id' kolom. Een kolom bevat niet 'id', een kolom bevat een userid, of een postid, vul maar in, maar het id is altijd van een entiteit binnen je database en daar dient de naam melding van te maken.

Waarom; nou los van "omdat het logisch is"; het is gewoon onhandig als al je tabellen een kolom 'id' hebben. Koppel de user tabel aan de forumposts en select daar eens * van, dan krijg je twee resultaatkolommen genaamd 'id'. Welke is dan van de user en welke van de forumposts? Dat kun je wel afvangen met aliassen: SELECT user.id AS userid, forumposts.id AS forumposts, maar.... uhm... als je in de query een onduidelijke kolomnaam gaat verduidelijken dan ben je toch wel fout bezig.

In het verlengde hiervan; in de forumposts tabel zit uiteraard het id van de user die de post gedaan heeft. Noem die kolom dus niet userid, want er staat niet zomaar een leuk userid in, er staat in wie de post gedaan heeft.; poster_userid dus. Er is geen twijfel mogelijk over wat er in de kolom 'poster_userid' staat.

En nu ik toch bezig ben. Afkortingen. Probeer ze te voorkomen en gebruik ze alleen als het echt volledig ingeburgerd is. Waarom: ik heb veel te veel databases gezien met een uid, een gid, een pid, tid, sid, tid en wid, waarbij de progammeurs een kladblokje naast hun toetsenwordt hadden liggen met de verklarende woordenlijst.
Afkorgen maakt je query niet duidelijker en op performance heeft het al helemaal geen enkele invloed.