Wie funktionieren Modelle und das ORM?

Question

Accepted Answer

Ein **Modell** ist eine Python-Klasse, die die Struktur deiner Daten definiert — jedes Modell ist einer Datenbanktabelle zugeordnet, und jedes Attribut einer Spalte. Das **ORM (Object-Relational Mapper)** ermöglicht es dir, mit der Datenbank über Python-Objekte und Methoden zu interagieren, statt rohes SQL zu schreiben.

## Ein Modell definieren

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

Jedes Modellfeld ist einer Datenbankspalte mit einem angemessenen Typ zugeordnet. Das Ausführen von Migrationen erstellt die entsprechende Tabelle — du schreibst selbst niemals `CREATE TABLE`.

## CRUD mit dem ORM (kein 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()
```

Das ORM übersetzt diese Python-Aufrufe automatisch in SQL. Feldsuchen (`__icontains`, `__gte`, `__in` usw.) drücken WHERE-Bedingungen pythonisch aus.

## Warum ein ORM? Vorteile und Kompromisse

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

## Modelle sind die einzige Wahrheitsquelle (DRY)

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

## Warum es wichtig ist

Modelle und das ORM sind zentral für Django — sie sind der Weg, wie du die Daten deiner Anwendung definierst und damit arbeitest, was das Herz der meisten Webanwendungen ist.

Sie zu verstehen ist wesentliches alltägliches Wissen: Modelle definieren deine Datenstruktur (Abbildung von Klassen auf Tabellen, Attribute auf Spalten) und dienen als **einzige Wahrheitsquelle**, die das Datenbankschema, die Admin-Oberfläche, Formulare und API-Serializer antreibt (die DRY-Philosophie).

Das ORM ermöglicht es dir, Datenbankoperationen in sauberem, lesbarem **Python statt SQL** zu schreiben, mit großen Vorteilen: Datenbankportabilität (der gleiche Code läuft auf verschiedenen Datenbanken), enge Integration mit dem Rest von Django, und entscheidend **Sicherheit** (es verwendet standardmäßig parametrisierte Anfragen und verhindert SQL-Injection).

Zu wissen, wie man Modelle mit angemessenen Feldern definiert, CRUD-Operationen durchführt und mit der Lookup-Syntax des ORM abfragt, ist grundlegend für den Aufbau jeder Django-Anwendung.

Gleich wichtig ist das Bewusstsein für den **Kompromiss** des ORM — dass praktische Abfragen ohne Sorgfalt ineffizient werden können (das N+1-Problem) —, was zu Optimierungstechniken führt.

Die Modell-/ORM-Schicht ist der Ort, wo Django-Anwendungen einen großen Teil ihrer Logik verbringen, was sie zu zentralem, unverzichtbarem Material macht.