Eerst: wat is een databanktype?
Datatype = manier waarop data wordt gestructureerd + opgezocht + geschaald.
Niet elk type is "beter". Het hangt af van het probleem.
Belangrijk inzicht: kies de databank op basis van querypatroon, schaal en consistentiebehoefte.
Het grote overzicht
| Type | Voorbeeld | Model | Sterk in |
|---|
| Relationeel | SQLite | Tabellen + SQL + relaties | Structuur, integriteit, transacties |
| Key-Value | Redis | sleutel → waarde | supersnelle reads/writes, caching |
| Wide-Column | Cassandra | kolomfamilies, denormalisatie | grote schaal, hoge beschikbaarheid |
| Document | MongoDB | JSON-achtige documenten | flexibele schema's |
| Graph | Neo4j | nodes + edges | relaties en paden |
| Search Engine | Elasticsearch | geïndexeerde documenten | full-text search, aggregaties |
| Vector | Pinecone/Milvus/pgvector | embedding vectors | semantische zoekopdrachten (AI) |
SQLite: wat moet je echt goed kennen
- Relationeel model: tabellen, rijen, kolommen, sleutels.
- SQL-basis:
SELECT, INSERT, UPDATE, DELETE.
- Relaties:
PRIMARY KEY, FOREIGN KEY, JOINs.
- Datakwaliteit:
NOT NULL, UNIQUE, CHECK.
- Transacties:
BEGIN / COMMIT / ROLLBACK.
SQL sterke punten
- Gestandaardiseerde querytaal die in veel relationele databanken werkt.
- Sterk voor gestructureerde data, relaties en duidelijke constraints.
- Joins en aggregaties maken rapportering en analyse krachtig.
- Transacties maken data betrouwbaar bij fouten of onderbrekingen.
We gebruiken SQLite in de les omdat het makkelijk opstart: geen server, wel echte SQL.
SQLite beperkingen
- Niet ideaal voor heel veel gelijktijdige schrijfbewerkingen.
- Schaalt minder horizontaal dan gedistribueerde systemen.
- Minder geschikt voor enorme cloud-workloads met miljoenen requests/sec.
Belangrijk: "niet ideaal" voor mega-schaal betekent niet "slecht" voor normale apps.
Kernvoorbeeld (SQLite schema)
CREATE TABLE users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
username TEXT NOT NULL UNIQUE,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE messages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
message TEXT NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id)
);
Kernvoorbeeld (SQLite query)
SELECT m.id, u.username, m.message
FROM messages m
JOIN users u ON u.id = m.user_id
ORDER BY m.id DESC;
Dit relationele denken blijft de basis waarop je andere types beter begrijpt.
Key-Value databases (Redis)
key -> value
"session:123" -> "{ userId: 8, role: 'student' }"
- Heel snel in-memory.
- Eenvoudig model, extreem snelle toegang via sleutel.
- Vaak gebruikt als cache, sessie-opslag, rate-limiting.
Redis: wanneer wel / wanneer niet
Goed voor
- Login-sessies
- Tijdelijke data met TTL
- Realtime counters
- Caching van API-responses
Minder goed voor
- Complexe relationele query's
- Veel ad-hoc rapportering
- Zware joins
Redis vervangt SQLite meestal niet; het is vaak een aanvulling ernaast.
Wide-Column databases (Cassandra)
- Gebouwd voor distributie over veel servers (clusters).
- Geoptimaliseerd voor hoge write-throughput en beschikbaarheid.
- Data wordt vaak gemodelleerd per query/use-case (denormalisatie).
Je ontwerpt tabellen op basis van: "Welke query moet supersnel zijn?"
Cassandra kernbegrippen
- Partition key: bepaalt op welke node data staat.
- Clustering columns: sortering binnen partitie.
- Replicatie over nodes voor fault tolerance.
- Tunable consistency: keuze tussen sneller of consistenter.
Moeilijker datamodel dan SQL voor beginners. Eerst SQLite stevig begrijpen.
Document databases (MongoDB)
Document (JSON/BSON) voorbeeld:
{"_id": 1, "name": "Amina", "skills": ["SQL","JS"], "address": {"city": "Gent"}}
- Flexibel schema: niet elk document hoeft exact dezelfde velden te hebben.
- Past goed bij data die natuurlijk JSON-achtig is.
- Snelle iteratie in projecten waar model nog evolueert.
MongoDB: sterktes en valkuilen
Sterk
- Schema-flexibiliteit
- Natuurlijke mapping met JS-objecten
- Sharding mogelijk voor schaal
Valkuil
- "Schema-vrij" is niet "structuur-vrij"
- Data-inconsistentie zonder duidelijke regels
- Soms complexe aggregatie nodig
Best practice: ook bij Mongo schema-afspraken maken (validatie, conventies).
Graph databases
Let op: GraphQL is geen databank. GraphQL is een API-querytaal.
Een graph databank is bv. Neo4j.
Node: Persoon
Edge: VRIEND_VAN / KOCHT / VOLGT
Graph query: "vrienden van vrienden die product X kochten"
Wanneer graph DB gebruiken?
- Sociale netwerken en aanbevelingen.
- Fraudedetectie (verdachte netwerken/patronen).
- Route- en padproblemen.
- Kennisgrafen (semantische relaties).
Als je weinig relaties nodig hebt, is een relationele DB vaak eenvoudiger.
Search engines (Elasticsearch)
- Geen klassieke relationele DB, maar een zoek- en analyse-engine.
- Geoptimaliseerd voor full-text search.
- Ondersteunt scoring, fuzzy search, filters en aggregaties.
Zoekopdracht: "rode schoenen maat 42"
-> resultaten gerankt op relevantie
Elasticsearch in architectuur
Hoofddatabank (bv. SQLite/PostgreSQL) = waarheid (source of truth)
Elasticsearch = snelle zoeklaag op geïndexeerde kopie
Vaak gebruik je Elasticsearch naast je hoofd-DB, niet als enige opslag.
Vector databases
- Opslag van vectoren (embeddings): lijsten met getallen die betekenis coderen.
- Gebruik: semantische zoekopdrachten i.p.v. exacte woordmatch.
- Belangrijk bij AI-toepassingen: RAG, aanbevelingen, "zoek op betekenis".
"Hoe bak ik pizza?" en "recept voor pizza" liggen dicht bij elkaar in vectorruimte.
Vector DB kernidee
- Document -> embedding model -> vector.
- Query -> embedding -> nearest neighbor search (ANN).
- Resultaat: meest semantisch gelijkaardige items.
Vector search vervangt klassieke SQL-filters niet; combineer ze vaak.
Vergelijking per eigenschap
| Eigenschap | SQLite | Redis | MongoDB | Cassandra |
|---|
| Schema | strikt | simpel key-value | flexibel | query-gedreven |
| Joins | ja | nee | beperkt/anders | meestal nee |
| Transacties | sterk | beperkt use-case | aanwezig | andere trade-offs |
| Schaal horizontaal | beperkt | goed | goed | zeer sterk |
| Typisch gebruik | app-data | cache/session | content/events | massale data streams |
Hoe kies je de juiste databank?
- Welke queries zijn kritisch?
- Hoeveel data en hoeveel gebruikers tegelijk?
- Is sterke consistentie nodig of primeert beschikbaarheid/snelheid?
- Hoeveel complexiteit kan het team onderhouden?
- Moet het systeem vooral zoeken op tekst of op betekenis?
Praktische architectuur (realistisch)
SQLite/PostgreSQL -> hoofddata en transacties
Redis -> caching en sessies
Elasticsearch -> zoekfunctionaliteit
Vector DB -> semantische AI-zoeklaag
Dit heet polyglot persistence: meerdere databanken, elk voor een specifieke taak.
Examenvragen waarop je moet kunnen antwoorden
- Waarom is SQLite geschikt voor jullie chat/login-opdrachten?
- Wanneer zou je Redis toevoegen naast SQLite?
- Wat is het fundamentele verschil tussen MongoDB en SQLite?
- Waarom is GraphQL geen graph databank?
- Wanneer gebruik je Elasticsearch i.p.v. SQL
LIKE?
- Wat is een vector embedding en waarom is dat nuttig?
Korte cases (toepassen)
- Chatapp met eenvoudige gebruikers en berichten -> SQLite.
- Heel snelle login-sessies + rate limiting -> Redis erbij.
- Productcatalogus met vrije producteigenschappen -> MongoDB mogelijk.
- Zoekbalk met typo-tolerantie -> Elasticsearch.
- "Vind gelijkaardige documenten" -> Vector DB.
Wat je zeker moet studeren
- SQLite: tabellen, sleutels, joins, constraints, transacties.
- Per ander type: model + 3 use-cases + 2 beperkingen.
- Kunnen uitleggen waarom je vaak meerdere databanken combineert.
Leer niet alleen "definities". Oefen op keuzes verantwoorden.
Samenvatting
- SQLite is jullie basis en moet je grondig beheersen.
- Andere types lossen andere problemen op: snelheid, schaal, zoekkwaliteit, semantiek.
- Er bestaat geen universeel beste databank; context bepaalt de keuze.
- Sterke developers kiezen bewust en kunnen die keuze uitleggen.