Lagring

Den del av IT-sektorn som varit min kontaktyta mot arbetslivet kan sammanfattas i följande mening. Data kommer in, lagras och plockas ut för presentation. Svårare än så är det inte. Låt oss titta närmare på den mellersta delen lagring. Jag vill lyfta fram några problemställningar och förändringar.

De stora databaserna som DB2, Oracle och SQL-server har dominerat. Gemensamt är stödet för en allmän SQL-standard men också väl tilltagen prissättning och minimering av förändringsbenägenheten. Stödet för stora objekt så kallade Blob:ar har tillförts liksom implementering av XML. Förändringar som kommit sent. Först när marknaden tagit andra vägar.

Från utbildningstiden drar vi oss till minnes tragglandet av normalformerna. Allt för att hitta uppdelningen av tabeller och varje tabells unika nyckelvärde. Senare har användandet av surrogatnycklar tillkommit för att underlätta arbetet med SQL-satser. Problematiken mellan objekthanteringen och databas har varit föremål för en omfattande debatt. Den som gått under namnet ORM, object relational mapping. Hela framework har växt fram. Inom java-världen är Hibernate det mest kända.

Genom de stora drakarnas prissättning kom mySQL gratisversion som en frisk fläkt och blev defaktostandard för webapplikationer. Det är dock en annan tendens jag vill lyfta fram. Drakarnas tröghet har banat väg för något som går under namnet NoSQL. Till en början fanns tolkningen “no SQL” dvs säga nej till SQL-databaserna. Senare förtydligat till “not only SQL”. Inom termen ryms ett brett spektra av olika lagringsformer. De vanligaste kan hänföras till någon av grupperna “key value store”, “column based”, “document database” eller “graph database”.

I gruppen dokumentdatabaser som får betraktas som efterföljare till Lotus Notes finns bland annat MongoDB. En databas som jag försökt tillföra min verktygsportfölj. Flexibiliteten är en av fördelarna jag ser. Det finns ingen låsning till en statisk tabellstruktur. Den är också lätt att ta till sig om man kommer från SQL-lägret. Här finns också lagringen av stora objekt som alternativ till de traditionella blobarna.

En annan grupp som intresserat mig är är graph databaserna. Därför har jag placerat Neo4J på undersökningsbordet. Uppgifterna i databasen är noder eller relationer mellan noderna. Varje nod eller relation kan ha egenskaper. Í deras argumentering för databasen framhålls prestandan. Jämfört med en traditionell databas kan Neo4j för många applikationer erbjuda en prestandaförbättring upp till tusen gånger. Nu har jag inte utsatt detta för granskning utan min infallsvinkel är en annan. Kan applikationerna förenklas med denna typ av lagring? Jag är beredd att svara ja på den frågan. Flexibiliteten är stor. Potential finns. Problematiken är snarare låsningen av tankemönstren till SQL-modellen.