Hvordan fungerer modeller og ORM?

Question

Accepted Answer

En **modell** er en Python-klasse som definerer strukturen på dataene dine — hver modell samsvarer med en databasetabell, og hvert attributt samsvarer med en kolonne. **ORM (Object-Relational Mapper)** lar deg samhandle med databasen ved å bruke Python-objekter og metoder i stedet for å skrive rå SQL.

## Definere en modell

```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 modell-felt samsvarer med en databasekolonne med en passende type. Når du kjører migrasjoner, opprettes den tilsvarende tabellen — du skriver aldri `CREATE TABLE` selv.

## CRUD med ORM (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 oversetter disse Python-kallene til SQL automatisk. Felt-oppslag (`__icontains`, `__gte`, `__in`, osv.) uttrykker WHERE-betingelser på pythonisk måte.

## Hvorfor en ORM? Fordeler og avveiinger

```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 kilden til sannhet (DRY)

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

## Hvorfor det betyr noe

Modeller og ORM er sentrale i Django — de er hvordan du definerer og arbeider med applikasjonens data, som er hjertet i de fleste webapplikasjoner.

Å forstå dem er vesentlig daglig kunnskap: modeller definerer datastrukturen din (kartlegger klasser til tabeller, attributter til kolonner) og fungerer som **den eneste kilden til sannhet** som driver databaseskjemaet, admin-grensesnittet, skjemaer og API-serializere (DRY-filosofien).

ORM lar deg skrive databaseoperasjoner i rens, lesbar **Python i stedet for SQL**, med store fordeler: databareportabilitet (samme kode kjører på ulike databaser), stram integrasjon med resten av Django, og kritisk viktig **sikkerhet** (den bruker parameteriserte spørringer som standard, noe som forhindrer SQL-injeksjon).

Å kunne definere modeller med passende felt, utføre CRUD-operasjoner og stille spørsmål med ORM-ens oppslags-syntaks er grunnleggende for å bygge en hvilken som helst Django-applikasjon.

Like viktig er oppmerksomheten på ORM-ens **avveiing** — at praktiske spørringer kan bli ineffektive (N+1-problemet) uten forsiktighet — som fører til optimaliseringsteknikker.

Modell-/ORM-laget er der Django-applikasjoner bruker mye av logikken sin, noe som gjør det til kjernestoff som må mestres.