Att välja bra datatyper i system och databaser är viktigt. Tidigare snålade man ofta på storleken för att minska lagringsvolymerna och förbättra prestanda. Idag är det inte lika viktigt längre, även om det kan spela roll i vissa tillämpningar. Prioritera i stället datatyper som är väl lämpade för uppgiften och som gör att ditt system kan växa smärtfritt.
Heltal har goda prestandaegenskaper och lämpar sig bra för internt systemdata som till exempel primärnycklar, index och räknare i loopar. Normalt representeras heltal med 32 bitar, men riskerar man tal på över 2 miljarder bör man överväga 64 bitar (bigint).
Med verksamhetsdata ska man vara försiktig med att använda heltal. Det visar sig ofta att det man tror måste vara heltal inte alltid är det. 2,5 person kan vara ett högst relevant värde vid resursuppskattning.
UUID/GUID används ibland för primärnycklar. De ger ett globalt unikt värde över alla tabeller och databaser. Att nyckeln är unik kan dock ej helt garanteras, även om kollisioner är extremt osannolika. Nyckeln kan också läcka information om på vilken dator och vid vilken tid den genererades.
Binära flyttal är det som oftast lämpar sig bäst för storheter, dvs. tal som beskriver en kvantitet (till exempel vikt, längd eller antal). Idag vinner man sällan prestanda genom att använda heltal i stället för flyttal.
Binära flyttal kan dock inte alltid representera decimaltal exakt. Till exempel kan 0,2 inte att exakt beskrivas med ett binärt flyttal. Ofta är det inte ett stort problem, men kan ge avrundningsfel i beräkningar.
Decimaltal bör användas för tal som måste stämma exakt med vad man får om man ”räknar för hand”, vilket kan vara viktigt inom bokföring. I vissa fall ger de bättre noggrannhet än binära flyttal, men andra fall sämre (de har ofta större precision, men mindre omfång). För att få korrekta resultat kräv att man vet vilka regler för avrundning som används.
Nummer är tal som inte är storheter, till exempel gatunummer, varunummer, paragrafnummer. De ska lagras som text. För eller senare kommer de nästan alltid att innefatta bokstäver eller andra tecken, likt gatunummer 20A eller paragraf 2.4.3. Detta är extremt vanligt även om kravställaren säger att det inte kommer att ske. En nackdel med lagring som text är att sorteringen kan bli tokig (1, 13, 7). Det kan avhjälpas med ett separat fält för sortering (till exempel med inledande nollor).
Klockslag bör helst lagras i universell tid (UTC) och konverteras till lokal tid i gränssnittet. Det underlättar om systemet blir internationellt vilket många blir.
Sommartid är dock något som kan ställa till det för återkommande händelser i framtiden. Då kan den lokala tiden ändras vid övergången till och från sommartid vilket kanske inte är önskvärt. Många kalenderprogram spar därför enskilda möten i UTC, men repetitiva möten i lokal tid.
Datum bör lagras som enbart datum utan tidstämpel. Tidigare var det också vanligt att man använde pseudodatum i form av heltal i data warehouse, där till exempel 20210731 stod för den sista juli 2021. Den lösningen ställer dock till problem när man behöver räkna på datum, till exempel lägga till tre månader. Den är dessutom onödigt idag då det finns en dedicerad datatyp för datum (som dessutom är kompaktare än en 32 bitars integer).
Något som kan ställa till det är okända eller saknade datum. En vanlig lösning är att man använder ett fiktivt datum (till exempel 9999-12-31). Det kan ge stora fel om man inte är medveten om att detta inte är ett riktigt datum. NULL är att föredra.
Veckonummer är något man bör undvika. De ställer lätt till med problem, dels finns olika standarder för hur man räknar ut veckonummer och den svenska metoden stöds inte av Excel. Dessutom kan samma veckonummer förekomma två gånger under samma år. 2019 var ett år med två vecka 1, en i början och en i slutet.
Formatering kan vara knepigt. Ska man lagra bindestrecket i ett personnummer eller blanksteg i ett telefonnummer. Den puritanska datamodeleraren säger nej. Lagra bara det som är ren information. Men ibland kan formateringen bära information och då bör den lagras. I äldre system byttes bindestrecket i personnummer ut mot ett plustecken när personen fyllt hundra. Ett ganska dumsnålt sätt för att spara sekelsiffran. Ibland kan det dock finnas skäl att lagra både formaterat och oformaterat data. Adressregister brukar ofta innehålla förnamn, efternamn samt ett displayname, som inte alltid är för- plus efternamn rakt av.
Använd helst datatyper som är väl etablerade. Det underlättar integration med andra system samt migreringar till nya plattformar.
… och undvik bråk ;-)
