Introdução

Models.py é o ponto onde muitos projetos Django dão errado. Modelagem confusa, migração quebrada e regra espalhada causam bugs silenciosos. Neste artigo, mostro como entender, escrever e manter Models.py corretamente, usando ORM na prática. Ao final, você conseguirá criar modelos consistentes, migrar com segurança e evitar erros comuns em produção.

O que é Models.py no Django

Models.py define a camada de dados do Django. Cada classe representa uma tabela. Cada atributo vira uma coluna. Na prática, o arquivo descreve como seus dados existem e se relacionam.

O Django usa o ORM para traduzir essas classes em SQL. Você não escreve CREATE TABLE. Você escreve Python. Testei isso em projetos pequenos e APIs grandes. Quando o modelo está correto, o resto flui.

Models.py também centraliza regras importantes:

  • Tipos de dados

  • Restrições

  • Relacionamentos

  • Comportamentos do domínio

Se o modelo está errado, o sistema inteiro sofre.

Por que Models.py é crítico no projeto

Na prática, Models.py define o limite do seu sistema. Views, serializers e formulários dependem dele. Um campo mal definido gera:

  • Migrações problemáticas

  • Dados inconsistentes

  • Validações duplicadas

Quando bem feito, acontece o oposto:

  • Menos código repetido

  • Queries legíveis

  • Evolução previsível do banco

Em projetos reais, percebi que 90% dos bugs de dados começam no modelo.

Float em Python: guia prático com exemplos

Se você já entendeu variáveis, aplique o conceito com números decimais. Leia o guia prático sobre float em Python, com exemplos reais e erros comuns:

Entender float em Python

Estrutura básica de um Models.py

Todo modelo herda de models.Model. O Django cria o id automaticamente. Não tente reinventar isso.

 
from django.db import models class Produto(models.Model): nome = models.CharField(max_length=100) preco = models.DecimalField(max_digits=8, decimal_places=2) ativo = models.BooleanField(default=True) def __str__(self): return self.nome

Esse código gera uma tabela com colunas claras. Testei esse padrão em e-commerce e ERP. Funciona.

Pontos importantes:

  • max_length é obrigatório em CharField

  • DecimalField é obrigatório para dinheiro

  • __str__ ajuda no admin e debug

Campos mais usados e quando aplicar

Escolher o campo errado gera dívida técnica. Use com critério.

Campos de texto

  • CharField: textos curtos, nomes, títulos

  • TextField: descrições longas

Evite TextField sem necessidade. Ele impacta indexação.

Campos numéricos

  • IntegerField: contadores

  • PositiveIntegerField: quantidades

  • DecimalField: valores financeiros

Nunca use FloatField para dinheiro. Já vi arredondamento quebrar relatórios.

Datas e horários

 
created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True)

Esse padrão resolve auditoria básica. Uso em todos os projetos.

Relacionamentos

Relacionamentos são o coração do ORM.

 
class Pedido(models.Model): cliente = models.ForeignKey( 'Cliente', on_delete=models.PROTECT, related_name='pedidos' )

Escolha bem o on_delete. Erro comum é usar CASCADE sem pensar. Em produção, isso apaga dados críticos.

O que é programar na prática?

Entenda como a programação funciona no dia a dia, o que realmente significa programar e como isso se aplica fora da teoria.

Entender como programar

Entendendo null, blank e default

Esse trio causa confusão até hoje.

  • null: afeta o banco

  • blank: afeta formulários

  • default: valor automático

Na prática:

 
email = models.EmailField(null=True, blank=True)

Use null=True apenas quando o banco permitir ausência real. Para texto, prefira blank=True.

Migrações: onde muitos erram

Models.py e migrações caminham juntos. Alterou o modelo? Gere migração.

 
python manage.py makemigrations python manage.py migrate

O erro mais comum que observei:

  • Alterar campo em produção sem planejar dados existentes

Exemplo perigoso:

  • Tornar campo obrigatório sem default

Sempre revise a migração gerada. Não aceite automaticamente.

Métodos e regras dentro do modelo

Regra de negócio pertence ao modelo. Não jogue tudo na view.

 
class Produto(models.Model): preco = models.DecimalField(max_digits=8, decimal_places=2) def aplicar_desconto(self, percentual): return self.preco * (1 - percentual / 100)

Isso mantém a lógica perto do dado. Testei esse padrão com Django REST Framework. Facilita testes e manutenção.

Boas práticas que evitam retrabalho

Esses pontos vieram de erros reais:

  • Use nomes no singular

  • Evite modelos gigantes

  • Separe apps por domínio

  • Documente campos complexos

  • Use choices para estados fixos

 
STATUS = ( ('P', 'Pendente'), ('A', 'Aprovado'), ) status = models.CharField(max_length=1, choices=STATUS)

Isso evita valores inválidos no banco.

Models.py em projetos grandes

Quando Models.py cresce demais, divida.

 
models/ ├── produto.py ├── pedido.py └── cliente.py

No __init__.py, importe os modelos. Esse padrão mantém legibilidade em sistemas grandes. Já usei em projetos com mais de 40 modelos.

Conclusão

Models.py é a fundação do Django. Ele define dados, regras e relações. Quando bem escrito, o ORM trabalha a seu favor. Quando mal planejado, vira gargalo.

Use tipos corretos, planeje migrações e centralize regras no modelo. Evite atalhos. Esse cuidado reduz bugs e acelera o projeto no médio prazo.

Aplique os padrões mostrados aqui. Revise seus modelos atuais. O ganho é imediato.