SQL eller NoSQL?

Min resa: Uppfödd på relationer

För mig – och säkert för många av er – har databaser alltid handlat om ordning och reda. Man ritar upp sitt ER-diagram, spikar sina datatyper, sätter upp relationer och litar blint på ACID-garantier. Det är en trygg värld där data alltid valideras innan det sparas.

I början av 2000-talet gjorde jag till och med ett webbaserat curlingspel (Ultimate Curling) med hela spellogiken i Stored Procedures, Views, Transactions, Triggers och Functions.

När NoSQL som MongoDB, DocumentDB eller Cosmos DB dök upp tittade jag såklart på dem för att se om det var något som kunde hjälpa mig. Jag fastnade inte helt för det då. Men det kan ha handlat om var mitt fokus var just då – i ERP-träsket där SQL åtminstone har varit standard.

Snabbguiden: När ska du byta spår?

Utmaning	Mitt SQL-svar	Mitt NoSQL-svar
Datastruktur	Strikt, stabil och känd på förhand	Föränderlig, flexibel och agil
Relationer	Djupa (Många JOINs och tabeller)	Platta (Allt sparas i samma dokument)
Skalning	Fixas med bättre hårdvara	Fixas med fler servrar (Kluster)
Viktigast	Datans korrekthet (t.ex. ekonomi)	Hastighet och tillgänglighet

Var har jag landat?

Beroende på applikation kan jag välja antingen SQL eller NoSQL. Det blir då oftast PostgreSQL eller MongoDB som blir valet.

Men jag har också insett att jag kan använda båda typerna i en och samma applikation beroende på syftet. Vissa saker mår helt enkelt väldigt bra i båda miljöerna.

Relationerna för spårbarheten tycker jag personligen mår bäst i en SQL-databas, men jag ser samtidigt en enorm styrka med NoSQL och dependency injection av modeller. NoSQL är inte här för att ersätta SQL. Det är ett komplement.