Hvordan fungerer modeller og ORM?

Question

Accepted Answer

En **model** er en Python-klasse, der definerer strukturen på dine data — hver model kortlægges til en databasetabel, og hvert attribut til en kolonne. **ORM'en (Object-Relational Mapper)** lader dig interagere med databasen ved hjælp af Python-objekter og metoder i stedet for at skrive rå SQL.

## Definition af en model

```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)
```

Hvert modelfeld kortlægges til en databasekolonne med en passende type. Når du kører migrationer, oprettes den tilsvarende tabel — du skriver aldrig `CREATE TABLE` selv.

## CRUD med ORM'en (ingen 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()
```

ORM'en oversætter disse Python-kald til SQL automatisk. Feltopslag (`__icontains`, `__gte`, `__in` osv.) udtrykker WHERE-betingelser pythonisk.

## Hvorfor en ORM? Fordele og kompromiser

```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
```

## Modeller er den eneste kilde til sandhed (DRY)

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

## Hvorfor det betyder noget

Modeller og ORM'en er centrale for Django — de er hvordan du definerer og arbejder med din applikations data, som er hjertet i de fleste webapplikationer.

At forstå dem er essentiell daglig viden: modeller definerer din datastruktur (kortlægning af klasser til tabeller, attributter til kolonner) og fungerer som **den eneste kilde til sandhed**, der driver databaseschemat, administratorgrænsefladerne, formularer og API-serialisere (DRY-filosofien).

ORM'en lader dig skrive databaseoperationer i ren, læsbar **Python i stedet for SQL**, med store fordele: databasebærbarhed (samme kode kører på forskellige databaser), tæt integration med resten af Django, og mest afgørende **sikkerhed** (den bruger parameteriserede forespørgsler som standard og forhindrer SQL-injektion).

At vide, hvordan man definerer modeller med passende felter, udfører CRUD-operationer og forespørger med ORM'ens opslags-syntaks, er grundlæggende for at bygge enhver Django-applikation.

Ligeså vigtigt er bevidsthed om ORM'ens **kompromis** — at bekvemme forespørgsler kan blive ineffektive (N+1-problemet) uden omhu — som fører til optimeringsteknikker.

Model-/ORM-laget er hvor Django-applikationer bruger meget af deres logik, hvilket gør det til kernestof, som man skal være dygtig til.