Hoe werken modellen en de ORM?

Question

Accepted Answer

Een **model** is een Python-klasse die de structuur van je gegevens definieert — elk model is gekoppeld aan een databasetabel, en elk kenmerk aan een kolom. De **ORM (Object-Relational Mapper)** stelt je in staat om met de database te werken met behulp van Python-objecten en -methoden in plaats van raw SQL te schrijven.

## Een model definiëren

```python
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)       # → VARCHAR column
    body = models.TextField()                        # → TEXT column
    published = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)  # set on creation
    views = models.IntegerField(default=0)

def __str__(self):
        return self.title                            # readable representation (admin, shell)
```

Elk modelveld is gekoppeld aan een databasekolom met een passend type. Het uitvoeren van migraties creëert de corresponderende tabel — je schrijft zelf nooit `CREATE TABLE`.

## CRUD met de ORM (geen SQL)

```python
# CREATE
article = Article.objects.create(title="Hello", body="...")

# READ — query with Python methods
Article.objects.all()                            # all rows → SELECT *
Article.objects.get(id=1)                         # one row by primary key
Article.objects.filter(published=True)            # WHERE published = true
Article.objects.filter(title__icontains="django") # WHERE title ILIKE '%django%'
Article.objects.exclude(views=0).order_by("-created_at")  # complex queries, chained

# UPDATE
article.title = "Updated"
article.save()
Article.objects.filter(published=False).update(published=True)  # bulk update

# DELETE
article.delete()
```

De ORM vertaalt deze Python-aanroepen automatisch naar SQL. Veldopzoeking (`__icontains`, `__gte`, `__in`, enzovoort) drukt WHERE-voorwaarden Pythonisch uit.

## Waarom een ORM? Voordelen en afwegingen

```text
✓ Write database code in Python — no SQL, more readable, less error-prone
✓ Database-agnostic — the same code works on PostgreSQL, MySQL, SQLite
✓ SECURITY — parameterized queries by default → prevents SQL injection
✓ Integrates with migrations, admin, forms (define the model once)
⚠️ Trade-off: can generate inefficient queries (e.g. N+1) if used carelessly —
   sometimes you need select_related/prefetch_related or raw SQL for complex cases
```

## Modellen zijn de enige bron van waarheid (DRY)

```text
One model definition drives: the database schema (migrations), the admin interface,
ModelForms, and serializers (DRF) — define it once, reuse everywhere.
```

## Waarom het belangrijk is

Modellen en de ORM zijn centraal in Django — dit is hoe je de gegevens van je toepassing definieert en ermee werkt, wat het hart van de meeste webtoepassingen is.

Het begrijpen ervan is essentiële dagelijkse kennis: modellen definiëren je gegevensstructuur (klassen toewijzen aan tabellen, kenmerken aan kolommen) en dienen als de **enige bron van waarheid** die het databaseschema, de beheerinterface, formulieren en API-serializers stuurt (het DRY-principe).

De ORM stelt je in staat om databasebewerkingen schoon en leesbaar in **Python in plaats van SQL** te schrijven, met grote voordelen: database-draagbaarheid (dezelfde code werkt op verschillende databases), nauwe integratie met de rest van Django, en cruciaal **veiligheid** (het gebruikt standaard geparameteriseerde query's, waardoor SQL-injectie wordt voorkomen).

Weten hoe je modellen met passende velden definieert, CRUD-bewerkingen uitvoert en query's met de opzoeksyntaxis van de ORM maakt, is fundamenteel voor het bouwen van elke Django-toepassing.

Evenals belangrijk is het bewustzijn van de **afweging** van de ORM — dat handige query's inefficiënt kunnen worden (het N+1-probleem) zonder zorg — wat leidt tot optimalisatietechnieken.

De model-/ORM-laag is waar Django-toepassingen veel van hun logica besteden, waardoor het kernmateriaal is dat je moet beheersen.