SQL eller NoSQL för ert system?

Valet mellan SQL och NoSQL låter som en teknisk detalj, men det formar hur ditt system beter sig i flera år. Det är också ett val där moden och entusiasm ofta leder fel. Här är beslutet på paradigmnivå, med en praktisk grundregel du kan luta dig mot.

Vad relationsmodellen ger dig gratis

En relationsdatabas (SQL) lagrar data i tabeller med ett bestämt schema och tydliga relationer mellan dem. Den strukturen kan kännas stel, men den ger tre saker utan att du behöver bygga dem själv.

• Transaktioner. Flera ändringar sker helt eller inte alls. Ett belopp dras från ett konto och landar på ett annat i samma svep – aldrig halvvägs. Så fort pengar, lager eller bokningar är inblandade är det här ovärderligt.
• Konsistens. Databasen vakar över att data hänger ihop. En order kan inte peka på en kund som inte finns, om du sagt åt den att bry sig om det.
• Ad hoc-frågor. Du kan ställa frågor du inte tänkte på när du byggde systemet – “hur många kunder i Göteborg beställde mer än tre gånger förra kvartalet” – utan att ha förberett just den vyn. Det är enormt värt när rapporteringsbehov dyker upp, och det gör de alltid.

Det du betalar är ett schema du måste hålla dig till och lite mer eftertanke i början. För de allra flesta system är det ett bra byte.

När NoSQL faktiskt vinner

NoSQL är ett paraply för databaser som medvetet frångår relationsmodellen. De löser verkliga problem – men specifika sådana.

En dokumentdatabas lagrar hela objekt (till exempel en produkt med alla sina varianter) som ett dokument. Det passar när data naturligt hänger ihop i klumpar och sällan behöver korsas mot annat, eller när strukturen skiljer sig kraftigt mellan poster.

En nyckel-värde-databas är i grunden en gigantisk uppslagsbok: ge en nyckel, få ett värde, blixtsnabbt. Perfekt för sessioner, cache och enkel lagring i stor skala.

Den gemensamma vinsten är skala och flexibilitet. NoSQL-databaser är byggda för att spridas över många servrar och svälja enorma datamängder, och de tvingar dig inte in i ett fast schema. Priset är att du ofta får ge upp fria frågor och starka transaktionsgarantier – exakt det relationsmodellen gav dig gratis.

Tumregeln: relationsdatabas tills motsatsen är bevisad

Om du är osäker, välj SQL. Det är den grundregel erfarna team landar i, och skälet är enkelt: relationsdatabasen är förlåtande. Den klarar en oväntad rapport, en ny relation och ett växande krav utan att du behöver bygga om. En modern relationsdatabas skalar dessutom långt – de flesta system når aldrig den volym där SQL blir flaskhalsen.

Byt till NoSQL när du har ett konkret, bevisat behov: datavolymer som en enskild relationsdatabas inte längre hanterar, en renodlad nyckel-värde-last, eller data vars struktur varierar så mycket att ett schema blir en tvångströja. Notera ordet bevisat. “Vi kanske behöver skala som en global jätte” är sällan ett verkligt behov för ett svenskt bolag som ännu inte lanserat.

De vanliga NoSQL-ångerfallen

Det typiska misstaget ser likadant ut gång på gång. Ett team väljer en dokumentdatabas tidigt, ofta för att den kändes modern och snabb att komma igång med. Allt går bra – tills verkligheten kommer ikapp.

Först vill någon ha en rapport som korsar data på ett nytt sätt. I en relationsdatabas hade det varit en fråga; nu blir det ett byggprojekt, för databasen är inte gjord för att koppla ihop saker den vägen. Sedan växer relationerna fram ändå: ordern behöver ju veta om kunden, kunden om sina fakturor. Man börjar bygga relationer för hand ovanpå en databas som valdes just för att slippa dem.

Slutet blir ofta en dyr migrering tillbaka till SQL, eller en halvmesyr där affärslogik som databasen borde skött läcker in i applikationskoden. Det är inte att NoSQL är dåligt – det användes bara för ett problem det inte var byggt för.

Så väg valet mot vad systemet faktiskt ska göra. Behöver du hjälp att läsa av vart ert bygger är på väg tittar vi på Weapp gärna på datamodellen tillsammans, och resonerar kring valet innan det sätter sig i koden.