SQL eller NoSQL til jeres system?
Vælg en relationsdatabase (SQL) som standard, og skift først til NoSQL når et konkret behov begrunder det. SQL giver transaktioner, konsistens og frie ad hoc-forespørgsler gratis. NoSQL vinder ved enorme datamængder, fleksible skemaer eller enkel nøgle-værdi-lagring. De fleste systemer passer bedst i en relationsdatabase.
Valget mellem SQL og NoSQL lyder som en teknisk detalje, men det former hvordan dit system opfører sig i flere år. Det er også et valg hvor mode og begejstring ofte fører på afveje. Her gennemgår vi beslutningen på paradigmeniveau med en praktisk grundregel du kan læne dig op ad.
Hvad relationsmodellen giver dig gratis
En relationsdatabase (SQL) gemmer data i tabeller med et bestemt skema og tydelige relationer mellem dem. Den struktur kan føles stiv, men den giver tre ting uden at du selv skal bygge dem.
- Transaktioner. Flere ændringer sker helt eller slet ikke. Et beløb trækkes fra én konto og lander på en anden i samme omgang, aldrig halvvejs. Så snart penge, lager eller bookinger er involveret, er det uvurderligt.
- Konsistens. Databasen våger over at data hænger sammen. En ordre kan ikke pege på en kunde der ikke findes hvis du har bedt den om at holde øje med det.
- Ad hoc-forespørgsler. Du kan stille spørgsmål du ikke tænkte på da du byggede systemet (“hvor mange kunder i Göteborg bestilte mere end tre gange i sidste kvartal?”) uden at have forberedt netop det view. Det er enormt meget værd når der dukker nye rapporteringsbehov op, og det gør der altid.
Prisen er et skema du skal overholde, plus lidt mere omtanke i starten. For langt de fleste systemer er det en god handel.
Hvornår NoSQL faktisk vinder
NoSQL er en paraplybetegnelse for databaser der bevidst afviger fra relationsmodellen. De løser reelle problemer, men specifikke af slagsen.
En dokumentdatabase gemmer hele objekter (f.eks. et produkt med alle dets varianter) som ét dokument. Det passer når data naturligt hænger sammen i klumper og sjældent skal krydses med andet, eller når strukturen varierer kraftigt fra post til post.
En nøgle-værdi-database er grundlæggende et gigantisk opslagsværk: Giv en nøgle, og få en værdi, lynhurtigt. Perfekt til sessioner, cache og enkel lagring i stor skala.
Den fælles gevinst er skala og fleksibilitet. NoSQL-databaser er bygget til at blive fordelt over mange servere og sluge enorme datamængder, og de tvinger dig ikke ind i et fast skema. Prisen er at du ofte må opgive frie forespørgsler og stærke transaktionsgarantier: præcis det relationsmodellen gav dig gratis.
Tommelfingerreglen: relationsdatabase indtil det modsatte er bevist
Er du i tvivl, så vælg SQL. Det er den grundregel erfarne teams ender med, og grunden er enkel: Relationsdatabasen er tilgivende. Den kan klare en uventet rapport, en ny relation og et voksende krav uden at du skal bygge om. En moderne relationsdatabase skalerer desuden langt. De fleste systemer når aldrig den volumen hvor SQL bliver flaskehalsen.
Skift til NoSQL når du har et konkret, påvist behov: datamængder som en enkelt relationsdatabase ikke længere kan håndtere, en rendyrket nøgle-værdi-belastning eller data hvis struktur varierer så meget at et skema bliver en spændetrøje. Bemærk ordet påvist. “Måske skal vi kunne skalere som en global gigant” er sjældent et reelt behov for en virksomhed der endnu ikke har lanceret.
Når NoSQL-valget fortrydes
Den typiske fejl ser ens ud gang på gang. Et team vælger en dokumentdatabase tidligt, ofte fordi den føltes moderne og hurtig at komme i gang med. Alt går godt indtil virkeligheden indhenter dem.
Først vil nogen have en rapport der krydser data på en ny måde. I en relationsdatabase havde det været én forespørgsel. Nu bliver det et byggeprojekt, for databasen er ikke lavet til at koble ting sammen på den måde. Så vokser relationerne frem alligevel: Ordren skal jo kende kunden, kunden sine fakturaer. Man begynder at bygge relationer i hånden oven på en database der blev valgt netop for at slippe for dem.
Det ender ofte med en dyr migrering tilbage til SQL eller en halvløsning hvor forretningslogik som databasen burde have håndteret, siver ind i applikationskoden. Det er ikke fordi NoSQL er dårligt. Det blev bare brugt til et problem det ikke var bygget til.
Så vej valget op mod hvad systemet faktisk skal kunne. Har du brug for hjælp til at aflæse hvor jeres projekt er på vej hen, kigger vi i Weapp gerne på datamodellen sammen med jer og drøfter valget før det sætter sig fast i koden.
Ofte stillede spørgsmål
Hvad er den vigtigste forskel på SQL og NoSQL?
SQL-databaser gemmer data i tabeller med et fast skema og relationer mellem dem. NoSQL er en samlebetegnelse for databaser der afviger fra den model (dokumenter, nøgle-værdi, grafer), ofte med en løsere struktur. Den praktiske forskel er at SQL giver dig konsistens og frie forespørgsler gratis mens NoSQL bytter en del af det ud med fleksibilitet og skala.
Er NoSQL hurtigere end SQL?
Ikke generelt. NoSQL kan være hurtigere til bestemte mønstre, f.eks. at slå et dokument op på en nøgle eller fordele enorme datamængder over mange servere. Men for de fleste systemer med normale datamængder er en velindekseret relationsdatabase mindst lige så hurtig og betydeligt mere tilgivende når forespørgslerne ændrer sig over tid.
Hvad menes der med transaktioner, og hvorfor betyder de noget?
En transaktion garanterer at flere ændringer sker helt eller slet ikke: Et beløb trækkes fra en konto og indsættes i samme omgang, aldrig kun det ene. Relationsdatabaser giver dette som standard. I mange NoSQL-databaser er garantierne svagere eller begrænsede, og det bliver et problem så snart penge, lager eller bookinger er involveret.
Kan man bruge både SQL og NoSQL i samme system?
Ja, og det er almindeligt. En relationsdatabase kan bære forretningsdata og kernelogik mens en nøgle-værdi-database håndterer sessioner eller cache, og et søgeindeks tager sig af fritekstsøgning. Pointen er at vælge det rigtige værktøj til hvert behov, ikke at ét paradigme skal eje hele systemet.
Hvad er nemmest at rekruttere til og vedligeholde?
SQL har et forspring. Relationsdatabaser har eksisteret i årtier, kompetencerne er brede og værktøjerne modne. NoSQL-kompetencer findes, men er mere nicheprægede pr. produkt. For et lille team uden særlige grunde er en relationsdatabase som regel billigst både at bemande og at drive over tid.