Jak działają modele i ORM?

Question

Accepted Answer

**Model** to klasa Pythona definiująca strukturę Twoich danych — każdy model odwzorowuje tabelę bazy danych, a każdy atrybut to kolumna. **ORM (Object-Relational Mapper)** pozwala Ci na interakcję z bazą danych przy użyciu obiektów Pythona i metod zamiast pisania surowego SQL.

## Definiowanie modelu

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

Każde pole modelu odwzorowuje kolumnę bazy danych o odpowiednim typie. Uruchomienie migracji tworzy odpowiednią tabelę — nigdy nie musisz sam pisać `CREATE TABLE`.

## CRUD z ORM-em (bez 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 automatycznie tłumaczy te wywołania Pythona na SQL. Operacje wyszukiwania w polach (`__icontains`, `__gte`, `__in`, itd.) wyrażają warunki WHERE w stylu Pythona.

## Dlaczego ORM? Korzyści i kompromisy

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

## Modele są jedynym źródłem prawdy (DRY)

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

## Dlaczego to ważne

Modele i ORM są centralne dla Django — to sposób, w jaki definiujesz i pracujesz z danymi aplikacji, co jest sercem większości aplikacji webowych.

Rozumienie ich jest niezbędną wiedzą codzienna: modele definiują strukturę Twoich danych (mapując klasy do tabel, atrybuty do kolumn) i służą jako **jedyne źródło prawdy** napędzające schemat bazy danych, interfejs administracyjny, formularze i serializatory API (filozofia DRY).

ORM pozwala Ci pisać operacje na bazie danych w czystym, czytelnym **Pythonie zamiast SQL**, z istotnymi korzyściami: przenośność bazy danych (ten sam kod działa na różnych bazach danych), ścisła integracja z resztą Django oraz crucially **bezpieczeństwo** (domyślnie używa sparametryzowanych zapytań, zapobiegając atakom SQL injection).

Wiedzenie, jak definiować modele z odpowiednimi polami, wykonywać operacje CRUD oraz wykonywać zapytania przy użyciu składni lookup ORM jest fundamentalne dla budowania jakiejkolwiek aplikacji Django.

Również ważna jest świadomość **kompromisu** ORM — że wygodne zapytania mogą stać się nieefektywne (problem N+1) bez opieki — co prowadzi do technik optymalizacji.

Warstwa model/ORM to miejsce, gdzie aplikacje Django spędzają wiele swojej logiki, co czyni ją materiałem kluczowym i obowiązkowym do opanowania.