Como modelos e o ORM funcionam?

Question

Accepted Answer

Um **modelo** é uma classe Python que define a estrutura de seus dados — cada modelo mapeia para uma tabela de banco de dados, e cada atributo para uma coluna. O **ORM (Object-Relational Mapper)** permite que você interaja com o banco de dados usando objetos e métodos Python em vez de escrever SQL bruto.

## Definindo um modelo

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

Cada campo do modelo mapeia para uma coluna de banco de dados com um tipo apropriado. Executar migrations cria a tabela correspondente — você nunca escreve `CREATE TABLE` você mesmo.

## CRUD com o ORM (sem 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()
```

O ORM traduz essas chamadas Python em SQL automaticamente. Lookups de campo (`__icontains`, `__gte`, `__in`, etc.) expressam condições WHERE de forma pythônica.

## Por que um ORM? Benefícios e trade-offs

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

## Modelos são a única fonte de verdade (DRY)

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

## Por que isso importa

Modelos e o ORM são centrais no Django — é assim que você define e trabalha com os dados de sua aplicação, que é o coração da maioria das aplicações web.

Compreendê-los é conhecimento essencial do dia a dia: modelos definem sua estrutura de dados (mapeando classes para tabelas, atributos para colunas) e servem como a **única fonte de verdade** que orienta o schema do banco de dados, interface de admin, formulários e serializadores de API (a filosofia DRY).

O ORM permite que você escreva operações de banco de dados em **Python limpo e legível em vez de SQL**, com benefícios principais: portabilidade de banco de dados (o mesmo código funciona em diferentes bancos de dados), integração estreita com o resto do Django, e crucialmente **segurança** (usa consultas parametrizadas por padrão, prevenindo SQL injection).

Saber como definir modelos com campos apropriados, executar operações CRUD e consultar com a sintaxe de lookup do ORM é fundamental para construir qualquer aplicação Django.

Igualmente importante é a consciência do **trade-off** do ORM — que consultas convenientes podem se tornar ineficientes (o problema N+1) sem cuidado — o que leva a técnicas de otimização.

A camada modelo/ORM é onde as aplicações Django gastam grande parte de sua lógica, tornando-a material principal e obrigatório de domínio.