DEV Community: Davi Domingos de Oliveira

Arquitetura Zero Cost: Como transformei o Git em um banco de dados temporal com GitHub Actions

Davi Domingos de Oliveira — Fri, 03 Apr 2026 02:49:00 +0000

1.A armadilha do Overengineering

Quando comecei a desenhar o Gado-Scraper, eu tinha um problema e uma restrição clara: eu precisava monitorar cotações pecuárias diariamente, mas, como estudante, meu orçamento para infraestrutura em nuvem era zero. É muito fácil, hoje em dia, puxar o cartão de crédito e provisionar um banco de dados relacional e uma função serverless na AWS para rodar um script de 1 minuto por dia. Mas eu não podia me dar a esse luxo. Essa restrição financeira me forçou a pensar fora da caixa e evitar a armadilha clássica do overengineering. Foi assim que descobri como transformar o próprio repositório no GitHub em um banco de dados temporal automatizado, com custo absolutamente zero.

Neste artigo, vou te mostrar exatamente como construí uma pipeline ETL de dados que roda todos os dias sem servidor, sem um banco de dados tradicional e com custo exatamente zero. Você vai ver na prática como transformei o próprio repositório no GitHub e o GitHub Actions em um banco de dados temporal automatizado.

2. A Mudança de Paradigma: "Git-as-a-Database"

Mas o que é Git-as-a-Database? Usar o repositório do GitHub como um banco de dados é uma premissa diferente do que o Git foi originalmente pensado, porém se encaixa perfeitamente com o rastreio de mudanças do sistema. Quando paramos para pensar, o Git foi criado com um propósito muito bem definido: rastrear o histórico de alterações em arquivos baseados em texto de forma imutável e cronológica. Bancos de dados tradicionais são incríveis, mas para salvar apenas a variação de uma ou duas cotações uma vez ao dia, eles são um exagero técnico.

Para eliminar a necessidade de um servidor 24h hospedado na nuvem, decidi usar o Github Actions no meu robô de captura. Configurei uma pipeline automatizada que, todo dia em horário de mercado executa meus scripts de web scraping escritos em Python.

O pulo do gato arquitetural acontece logo após a extração. Assim que o script coleta os valores da arroba, ele sobrescreve dois arquivos simples na raiz do projeto: cotacoes_boi_hoje.json e cotacoes_novilha_hoje.json. É aqui que a mágica acontece: em vez de abrir uma conexão pesada com a AWS e fazer um comando INSERT em um banco de dados na nuvem, a pipeline simplesmente faz um git push. O próprio repositório passa a funcionar como o banco de dados histórico. Todo o histórico de preços da pecuária fica perfeitamente preservado no git log, onde cada commit diário atua como um snapshot exato daquele dia, pronto para ser consumido por análises de séries temporais

3. Dissecando a Pipeline YAML

Todo o "cérebro" do robô de captura reside num único ficheiro de configuração YAML. É ele que orquestra toda a nossa infraestrutura efémera.

Logo no início do ficheiro, defini três gatilhos (on): o schedule com uma cron expression (0 9 * * *) configurada para rodar automaticamente todos os dias às 9h UTC (06h da manhã no horário de Brasília), garantindo a captura das cotações no início do dia antes da abertura dos mercados locais; o push para garantir que os dados atualizam caso eu faça alguma alteração no código; e o workflow_dispatch, que me permite disparar o robô manualmente com um botão caso a extração falhe por alguma instabilidade externa.

No entanto, havia um obstáculo técnico de segurança. Por padrão, os runners (servidores temporários) do GitHub Actions possuem permissão apenas de leitura no repositório. Como o nosso objetivo era que o script em Python sobrescrevesse os ficheiros JSON e fizesse o commit dos novos dados, eu precisava de dar autorização de escrita à máquina, tudo isso sem expor as minhas senhas ou criar tokens complexos.

A solução elegante foi ajustar as permissões do job usando a flag permissions: contents: write. Veja como ficou a estrutura real da pipeline:

YAML

name: Atualização Diária (Boi e Novilha)

on:
  push:             # Roda ao salvar
    branches: [ main ]
  schedule:
    - cron: '0 9 * * *'
  workflow_dispatch: # Permite disparo manual

jobs:
  raspagem-completa:
    runs-on: ubuntu-latest

    # PERMISSÃO DE ESCRITA É OBRIGATÓRIA PARA SALVAR O JSON
    permissions:
      contents: write

    steps:
      - name: 1. Baixar código do repositório
        uses: actions/checkout@v3

      - name: 2. Instalar Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'

      - name: 3. Instalar bibliotecas
        run: pip install -r requirements.txt

      - name: 4. Rodar Scraper do Boi
        run: python scraper_boi.py

      - name: 5. Rodar Scraper da Novilha
        run: python scraper_novilha.py

      - name: 6. Salvar arquivos JSON no GitHub
        run: |
          git config --global user.name 'Bot do Scraper'
          git config --global user.email 'actions@github.com'

          # Adiciona os dois arquivos gerados
          git add cotacoes_boi_hoje.json cotacoes_novilha_hoje.json

          # Só commita se tiver mudança
          git diff --quiet && git diff --staged --quiet || (git commit -m "Dados atualizados: $(date +'%Y-%m-%d')" && git push)

Ao definir contents: write, a pipeline ganha a autoridade necessária para fazer o auto-commit direto na branch principal assim que o Python finaliza a extração. Nenhuma configuração adicional, nenhum banco de dados provisionado e nenhum servidor para gerir.

4. Segurança de Execução: Prevenindo falhas na Pipeline

Se prestou atenção no Passo 6 do código acima, deve ter notado um comando Bash um pouco longo na hora de fazer o commit. Existe um motivo crítico para ele estar ali.

Um problema clássico de automações de CI/CD que fazem auto-commit é o pipeline crash (falha no job) quando o Git tenta fazer um commit, mas não existem ficheiros modificados para adicionar à staging area. Para garantir uma execução contínua, segura e resiliente, adicionei a seguinte trava lógica:

Bash

git diff --quiet && git diff --staged --quiet || (git commit -m "Dados atualizados: $(date +'%Y-%m-%d')" && git push)

O comando git diff --quiet atua como um inspetor de segurança do repositório. Como o meu script Python injeta automaticamente a data do dia na chave "data_coleta" do JSON, o repositório garante um snapshot histórico diário, gerando um registo contínuo da série temporal. No entanto, se eu precisar de disparar a pipeline manualmente (workflow_dispatch) mais de uma vez no mesmo dia para fins de debugging, a verificação do diff retorna silêncio (já que a data e os preços daquele dia específico já foram registados na primeira execução).

Quando isso acontece, o fluxo é encerrado de forma limpa, sem tentar forçar um commit vazio que faria a GitHub Action falhar e emitir um alerta de erro na infraestrutura. O repositório mantém-se contínuo, gerando a série temporal diária exata de que preciso, mas totalmente à prova de falhas de runtime em reexecuções no mesmo dia.

5. Distribuição de Dados: O fim da API Rest

Até aqui, resolvemos a automação da coleta (com GitHub Actions) e o armazenamento histórico (com Git-as-a-Database). Mas ainda faltava a última peça do quebra-cabeça: a distribuição.

Se eu não tenho um banco de dados tradicional rodando na nuvem, como o meu ERP Zootécnico (o Sistema de Gestão de Gado) vai consumir essas cotações atualizadas? A abordagem clássica ditaria que eu precisasse provisionar um servidor e subir uma API REST (usando Flask ou FastAPI) apenas para ler os arquivos JSON e devolver as respostas via HTTP. Ou seja, mais infraestrutura para monitorar e manter.

Foi aí que apliquei a regra de ouro da arquitetura minimalista: use o que já está pronto.

O GitHub possui uma rede de distribuição de conteúdo (CDN) global e nativa projetada para servir arquivos brutos. A cada commit que o robô faz atualizando o cotacoes_boi_hoje.json e o cotacoes_novilha_hoje.json, os dados ficam imediatamente disponíveis através do domínio raw.githubusercontent.com.

Na prática, eu transformei o próprio repositório em uma API estática. O meu sistema de gestão agora faz uma simples requisição HTTP GET direto para a URL Raw do GitHub. Ele consome o JSON mais recente de forma instantânea, servido por uma infraestrutura de altíssima disponibilidade bancada pela Microsoft, com custo absolutamente zero e sem precisar escrever uma única linha de código de rotas backend.

6. Conclusão: A Mentalidade FinOps

Todo projeto que eu me proponho a fazer me ensina algo. Um dos ensinamentos do Gado-Scraper foi: Nem sempre a solução mais complexa é a mais adequada. No final das contas, aquela limitação financeira citada no inicio do texto tornou esse projeto muito mais especial do que só um web scraper, foi toda uma jornada de busca de conhecimento para chegar nesse resultado satisfatório.

Quer dar uma olhada na pipeline YAML rodando ou usar o repositório como base para as suas próprias automações?

💻 Acesse o código-fonte: Dom1ng0s/Gado-Scraper no GitHub

Data Modeling for Agriculture: Combining Cash Flow and Average Daily Gain (ADG) in the Same Database

Davi Domingos de Oliveira — Fri, 03 Apr 2026 01:51:48 +0000

1. Introduction: A Real Problem on the Ground

When people talk about technology in agriculture, the conversation usually jumps straight to the flashy stuff — autonomous tractors, drone-mapped fields, and bleeding-edge IoT sensors. But that's the reality for a small minority. There's a quiet technological divide running through the agricultural sector that rarely makes headlines.

Livestock alone accounts for roughly 6–7% of Brazil's entire GDP. Yet 77% of rural properties in the country belong to small and mid-sized producers. So how does the vast majority of these operators manage the complexity of running a farm — tracking supplementation costs, live-weight commodity price swings, and the Average Daily Gain (ADG) of dozens or hundreds of animals? With paper notebooks, whiteboards, and generic spreadsheets that don't talk to each other.

As engineers, we have a name for this: Dark Data. Thousands of data points generated every single day, lost or severely underutilized simply because they were never captured in a relational database. Profit margins in modern livestock production are razor-thin, and making decisions based on unstructured data is a bottleneck worth billions of dollars.

In this post, I want to walk through the architecture of the Livestock Management System (LMS), a zootechnical ERP I built to bring structure to this long tail of agricultural data — with a particular focus on how I solved the project's most significant performance bottleneck.

2. The Technical Challenge: Python vs. the Database

2.1. Understanding the Bottleneck (The ADG Math)

ADG (Average Daily Gain) is an estimate of an animal's daily weight gain, typically measured in kilograms. Given a table structured like this:

CREATE TABLE IF NOT EXISTS pesagens (
    id INT AUTO_INCREMENT PRIMARY KEY,
    animal_id INT NOT NULL,
    data_pesagem DATE NOT NULL,
    peso DECIMAL(10, 2) NOT NULL,
    deleted_at DATETIME NULL DEFAULT NULL,
    FOREIGN KEY (animal_id) REFERENCES animais(id)
);

The ADG formula is straightforward: (Latest Weight - First Weight) / Days between first and last weigh-in.

On a working farm, this metric directly drives decision-making. It's the number that tells a rancher whether a nutrition protocol is working — or whether a particular animal is just burning through feed budget with nothing to show for it.

The real problem starts when you try to turn that simple formula into scalable code.

2.2. The Backend Processing Trap (The Python Anti-Pattern)

My first instinct was to use MySQL purely as a data store and let the Python backend handle all the computation — something roughly like this:

cursor.execute("SELECT animal_id, peso, data_pesagem FROM pesagens WHERE deleted_at IS NULL")
all_weigh_ins = cursor.fetchall()  # <--- THE BOTTLENECK STARTS HERE

herd_adg = {}

# Python doing the database's job
for record in all_weigh_ins:
    animal_id = record['animal_id']

    if animal_id not in herd_adg:
        herd_adg[animal_id] = {'weights': [], 'dates': []}

    herd_adg[animal_id]['weights'].append(record['peso'])
    herd_adg[animal_id]['dates'].append(record['data_pesagem'])

# Calculating ADG per animal with CPU-heavy loops
results = []
for animal_id, data in herd_adg.items():
    first_weight = min(data['weights'])
    last_weight  = max(data['weights'])

    first_date = min(data['dates'])
    last_date  = max(data['dates'])

    days = (last_date - first_date).days

    if days > 0:
        adg = (last_weight - first_weight) / days
        results.append({'animal_id': animal_id, 'adg': adg})

After the first load-testing round, I knew this approach was a dead end. The backend was carrying the full weight of raw computation, which caused a dramatic spike in server RAM consumption. The direct consequence: the system would slow down and eventually lock up as it scaled to more farms and larger herds.

3. The Solution: Push Intelligence into the Database

To fix the memory bottleneck, I flipped the logic entirely. Instead of pulling thousands of raw rows into Python and forcing the application layer to process them, why not do the math where the data already lives?

That's how I designed the "Performance-First" architecture of the LMS — delegating the heavy lifting to MySQL.

3.1. Optimized SQL Views and Window Functions

The centerpiece of this solution is a set of SQL Views. A View acts as a virtual table with the formula baked in. Instead of computing ADG on the fly in the backend at request time, I teach the calculation to the database itself.

To ensure the computation correctly reflects the chronological order of weigh-ins — even when an animal loses weight during a period — I used Common Table Expressions (CTEs) and Window Functions (ROW_NUMBER).

Here's how I structured the v_gmd_analitico view to solve this complex aggregation automatically:

CREATE OR REPLACE VIEW v_gmd_analitico AS
WITH PesagensOrdenadas AS (
    SELECT
        animal_id, data_pesagem, peso,
        ROW_NUMBER() OVER(PARTITION BY animal_id ORDER BY data_pesagem ASC) as rn_asc,
        ROW_NUMBER() OVER(PARTITION BY animal_id ORDER BY data_pesagem DESC) as rn_desc
    FROM pesagens
    WHERE deleted_at IS NULL
),
PrimeiraUltima AS (
    SELECT
        animal_id,
        MAX(CASE WHEN rn_asc = 1 THEN data_pesagem END) AS data_inicial,
        MAX(CASE WHEN rn_asc = 1 THEN peso END) AS peso_inicial,
        MAX(CASE WHEN rn_desc = 1 THEN data_pesagem END) AS data_final,
        MAX(CASE WHEN rn_desc = 1 THEN peso END) AS peso_final
    FROM PesagensOrdenadas
    GROUP BY animal_id
)
SELECT
    a.user_id, a.id as animal_id, a.brinco,
    p.peso_final,
    (p.peso_final - p.peso_inicial) as ganho_total,
    DATEDIFF(p.data_final, p.data_inicial) as dias,
    CASE
        WHEN DATEDIFF(p.data_final, p.data_inicial) > 0
        THEN (p.peso_final - p.peso_inicial) / DATEDIFF(p.data_final, p.data_inicial)
        ELSE 0
    END as gmd
FROM PrimeiraUltima p
JOIN animais a ON p.animal_id = a.id
WHERE p.data_inicial <> p.data_final
  AND a.deleted_at IS NULL;

Here's where the architecture pays off: when Flask needs to render a producer's dashboard, it no longer runs unbounded loops or pulls raw data across the network. The main listing queries the base animais table using server-side pagination, and the View is called surgically only when complex metrics are needed. MySQL handles all the grouping and guards against division-by-zero, delivering the zootechnical metric ready for aggregation — SELECT AVG(gmd) FROM v_gmd_analitico — or for building out a detailed animal profile page instantly.

3.2. Composite Indexes for Instant Lookups

Solving the ADG computation with a View was a major win, but what about when a producer wants to filter costs for a specific lot? Without proper indexing, MySQL would fall back to a Full Table Scan on every click — scanning the entire table regardless of how targeted the query was.

I addressed this with composite structural indexes — idx_pesagens_otimizada and idx_custos_busca being the two most critical. Even as a client registers thousands of animals over the years, every filtered lookup continues to return in milliseconds. The indexes effectively make query cost O(1) at the application layer, regardless of table size.

3.3. Server-Side Pagination and Connection Pooling

Two final rules govern the communication layer between the API and the database:

Server-Side Pagination: The main dashboard never loads the entire animal roster in a single response. I use LIMIT and OFFSET directly in MySQL queries, sending the browser only what fits on the current page.

Connection Pooling: Using mysql-connector-python, I configured a connection pool at database setup time. This eliminates the massive TCP overhead of opening and closing a new database connection on every incoming API request — the pool keeps connections warm and ready to reuse.

4. Results and Real-World Impact

The best architecture isn't the one built with the most fashionable tools — it's the one that eliminates the user's actual bottleneck in the smartest way. Shifting to a database-first approach delivered immediate, measurable gains on two fronts.

Business Impact: The End of Dark Data

A livestock producer who previously spent around 2 hours manually cross-referencing weigh-in notebooks with slow Excel files now has the complete farm picture in front of them. The dashboard delivers the full herd ADG analysis and consolidated cash flow in under 3 minutes. Dark data became actionable intelligence.

Technical Impact: A Server That Can Actually Scale

The Flask server is no longer choking on in-memory computation. RAM consumption dropped sharply because Python stopped pulling thousands of rows over the wire to do arithmetic it was never meant to do. With the SQL View absorbing the heavy calculation, composite indexes accelerating every filtered query, and pagination controlling data transfer, the system is genuinely production-scalable. Double or triple the number of registered animals — the dashboard still opens in milliseconds.

5. Conclusion

Generic software fails in agriculture because it treats a steer's live weight like SKU inventory in a retail system. Livestock is a living system, and its key performance indicators — like Average Daily Gain — demand an architecture designed around them, not bolted on as an afterthought.

In the end, good software solves real problems. Going from a rancher's operational pain to a production-grade SQL View using CTEs and Window Functions is what separates purpose-built tooling from off-the-shelf software dressed up with a new logo.

Want to dig into the code or see this architecture running live?

💻 Source code: Dom1ng0s/sistema_gado on GitHub
🚀 Live demo: Active deployment via Docker on Oracle Cloud: http://163.176.171.60

Appendix B: Brazilian Agribusiness Terms — A Translator's Note

Two terms in the original Portuguese source require special handling for an international engineering audience:

"Arroba" (@ — the Brazilian livestock weight unit)
In Brazilian cattle markets, live weight is quoted per arroba — a unit equivalent to 15 kg (approximately 33 lbs). When a rancher tracks the "price per arroba," they're tracking the live-weight commodity price used to calculate the market value of an animal at a given weight. For this article, I opted to avoid the term entirely and instead refer to "live-weight commodity price" and "market price per kilogram," which convey the same economic concept without requiring domain-specific context.

"Boi Gordo" (lit. "Fat Ox" / Finished Beef Steer)
Boi Gordo is the Brazilian futures market category for a grain-finished steer ready for slaughter — the rough equivalent of "fed cattle" in the CME Group's Live Cattle futures contract in the US. Price fluctuation in this category is what the article refers to when mentioning commodity price swings that affect profitability. I translated this simply as "live-weight commodity price" throughout to keep the focus on the economic signal rather than the Brazilian market nomenclature.

Modelagem de Dados no Agro: Unindo fluxo de caixa e Ganho Médio Diário (GMD) no mesmo Banco de Dados

Davi Domingos de Oliveira — Wed, 01 Apr 2026 02:43:53 +0000

1. Introdução: O Problema Real do Produtor

Quando se fala em tecnologia no agronegócio, é comum pensarmos imediatamente no "Agro 4.0": tratores autônomos, drones escaneando lavouras e sensores IoT de última geração. Porém, essa é a realidade de uma minoria absoluta. Existe um abismo tecnológico silencioso no campo brasileiro.

A pecuária sozinha representa cerca de 6% a 7% de todo o PIB nacional. No entanto, 77% das propriedades rurais do país pertencem a pequenos e médios produtores. E como a grande maioria desses produtores gerencia a complexidade de uma fazenda — calculando custos de suplementação, flutuação do preço da arroba e o Ganho Médio Diário (GMD) de dezenas ou centenas de animais? Usando cadernos de papel, quadros brancos ou planilhas genéricas que não se conversam.

Para nós, desenvolvedores, o nome disso é Dark Data (dados escuros). São milhares de pontos de dados gerados diariamente que são perdidos ou subutilizados porque não estão estruturados em um banco de dados relacional. O lucro na pecuária moderna está espremido em centavos, e tomar decisões baseadas em dados não estruturados é um gargalo de bilhões de reais.

Neste artigo, quero explorar a arquitetura do Sistema de Gestão de Gado (SGG), um ERP zootécnico que construí para estruturar essa "cauda longa" da pecuária, focando em como resolvi o maior gargalo de performance do projeto.

2. O Desafio Técnico: Python vs. Banco de Dados

2.1. Entendendo o Gargalo (A Matemática do GMD)

O GMD (Ganho Médio Diário), é a estimativa de crescimento diário de um animal, geralmente medido em Kg.
Numa tabela estruturada como:

        CREATE TABLE IF NOT EXISTS pesagens (
        id INT AUTO_INCREMENT PRIMARY KEY,
        animal_id INT NOT NULL,
        data_pesagem DATE NOT NULL,
        peso DECIMAL(10, 2) NOT NULL,
        deleted_at DATETIME NULL DEFAULT NULL,
        FOREIGN KEY (animal_id) REFERENCES animais(id)

O cálculo do GMD é dado como (Último Peso - Primeiro Peso)/Dias entre o primeiro e o último peso.

Numa fazenda, essa estatística afeta diretamente a tomada de decisão. É essa métrica que diz ao pecuarista se a dieta de nutrição está funcionando ou se o animal está apenas dando prejuízo.

O problema real começa quando tentamos transformar essa fórmula simples em código escalável

2.2. A Armadilha de Processar no Backend (O Risco do Python)

A minha primeira ideia foi usar o MySQL apenas para guardar as informações e usar o backend em Python para lidar com os cálculos, algo semelhante a:

cursor.execute("SELECT animal_id, peso, data_pesagem FROM pesagens WHERE deleted_at IS NULL")
todas_pesagens = cursor.fetchall() # <--- O GARGALO COMEÇA AQUI

rebanho_gmd = {}

# 2. O Python tentando fazer o trabalho do Banco de Dados
for registro in todas_pesagens:
    animal_id = registro['animal_id']

    if animal_id not in rebanho_gmd:
        rebanho_gmd[animal_id] = {'pesos': [], 'datas': []}

    rebanho_gmd[animal_id]['pesos'].append(registro['peso'])
    rebanho_gmd[animal_id]['datas'].append(registro['data_pesagem'])

# 3. Calculando o GMD animal por animal com loops (Alto consumo de CPU)
resultados = []
for animal_id, dados in rebanho_gmd.items():
    peso_inicial = min(dados['pesos'])
    peso_final = max(dados['pesos'])

    data_inicial = min(dados['datas'])
    data_final = max(dados['datas'])

    dias = (data_final - data_inicial).days

    if dias > 0:
        gmd = (peso_final - peso_inicial) / dias
        resultados.append({'animal_id': animal_id, 'gmd': gmd})

Porém, após a primeira bateria de testes, percebi que essa escolha era ineficiente, pois o backend ficaria responsável por boa parte dos cálculos brutos, aumentando drasticamente o consumo de RAM pelo servidor. A consequência direta disso seria a lentidão e o travamento do sistema à medida que o projeto escalasse para mais fazendas e rebanhos maiores.

3. A Solução: Inteligência no Banco de Dados

Para resolver o problema do alto consumo de RAM que mostrei no código anterior, decidi inverter a lógica. Em vez de trazer milhares de linhas brutas para o Python e forçar a aplicação a processá-las, por que não fazer a matemática onde os dados já estão armazenados?

Foi assim que estruturei a arquitetura "Performance-First" do Sistema de Gestão de Gado (SGG), delegando o processamento pesado ao MySQL.

3.1. Views SQL Otimizadas e Window Functions

A peça central dessa solução foi a criação de Views SQL. Uma View funciona como uma "tabela virtual". Em vez de calcular o Ganho Médio Diário (GMD) no backend em tempo real, eu ensino a fórmula matemática ao banco de dados.

Para garantir que o cálculo considerasse a ordem cronológica exata das pesagens (mesmo que um animal perdesse peso no período), utilizei Common Table Expressions (CTEs) e Window Functions (ROW_NUMBER).

Veja como estruturei a View v_gmd_analitico no meu banco para resolver esse cálculo complexo de forma automática:

CREATE OR REPLACE VIEW v_gmd_analitico AS
WITH PesagensOrdenadas AS (
    SELECT 
        animal_id, data_pesagem, peso,
        ROW_NUMBER() OVER(PARTITION BY animal_id ORDER BY data_pesagem ASC) as rn_asc,
        ROW_NUMBER() OVER(PARTITION BY animal_id ORDER BY data_pesagem DESC) as rn_desc
    FROM pesagens
    WHERE deleted_at IS NULL
),
PrimeiraUltima AS (
    SELECT 
        animal_id,
        MAX(CASE WHEN rn_asc = 1 THEN data_pesagem END) AS data_inicial,
        MAX(CASE WHEN rn_asc = 1 THEN peso END) AS peso_inicial,
        MAX(CASE WHEN rn_desc = 1 THEN data_pesagem END) AS data_final,
        MAX(CASE WHEN rn_desc = 1 THEN peso END) AS peso_final
    FROM PesagensOrdenadas
    GROUP BY animal_id
)
SELECT 
    a.user_id, a.id as animal_id, a.brinco,
    p.peso_final,
    (p.peso_final - p.peso_inicial) as ganho_total,
    DATEDIFF(p.data_final, p.data_inicial) as dias,
    CASE 
        WHEN DATEDIFF(p.data_final, p.data_inicial) > 0 
        THEN (p.peso_final - p.peso_inicial) / DATEDIFF(p.data_final, p.data_inicial)
        ELSE 0 
    END as gmd
FROM PrimeiraUltima p
JOIN animais a ON p.animal_id = a.id
WHERE p.data_inicial <> p.data_final
  AND a.deleted_at IS NULL;

"A mágica acontece aqui: Quando o Flask precisa processar os indicadores do pecuarista, ele não faz mais laços de repetição infinitos e não consome RAM desnecessária. A listagem principal consulta diretamente a tabela base de animais de forma paginada, enquanto a View é acionada cirurgicamente para as métricas complexas. O banco já resolve o agrupamento e previne divisões por zero, entregando o dado zootécnico pronto para extração de médias globais (ex: SELECT AVG(gmd) FROM v_gmd_analitico) ou para a montagem instantânea da ficha detalhada de cada animal.

3.2. Índices Compostos para Buscas Instantâneas

Ter a View resolveu o problema do cálculo do GMD, mas e quando o produtor quisesse buscar os custos de um lote específico? Para evitar que o MySQL fizesse um Full Table Scan (varrer a tabela inteira a cada clique), a modelagem precisava ser inteligente.

Implementei índices compostos estruturais, como o idx_pesagens_otimizada e o idx_custos_busca. Isso garantiu que, mesmo que o cliente cadastre milhares de animais ao longo dos anos, os filtros de busca continuem respondendo em milissegundos.

3.3. Paginação Server-Side e Pool de Conexões

Para fechar o "pacote" de alta performance, apliquei duas últimas regras na comunicação entre a API e o Banco:

Server-Side Pagination: O painel principal nunca carrega todos os animais de uma vez. Utilizo LIMIT e OFFSET diretamente nas queries do MySQL, enviando para o navegador apenas o que cabe na tela.
Connection Pooling: Usando a biblioteca mysql-connector-python, configurei um pool de conexões logo no setup inicial do banco. Isso evita o overhead gigantesco de abrir e fechar uma nova conexão TCP a cada nova requisição do usuário.

4. Resultados e Impacto Real

Na engenharia de software, a melhor arquitetura não é a que usa o maior número de ferramentas da moda, mas a que resolve o gargalo do usuário de forma inteligente. Ao adotar essa abordagem focada no banco de dados, o impacto foi imediato em duas frentes:

4.1. O Impacto no Negócio (O fim do Dark Data)

O pecuarista que antes gastava cerca de 2 horas cruzando dados de pesagens de cadernos para planilhas lentas no Excel, agora tem o cenário completo da fazenda. O painel entrega a análise de GMD do rebanho e o fluxo de caixa consolidados em cerca de 3 minutos. O dado escuro finalmente virou decisão.

4.2. O Impacto Técnico (Estabilidade do Servidor)

O meu servidor Flask agora "respira aliviado". O consumo de RAM da aplicação despencou, porque o Python parou de baixar milhares de linhas pela rede para fazer matemática básica. Com a View SQL resolvendo o cálculo, os índices otimizando os filtros e a paginação segurando o tráfego, o sistema se tornou verdadeiramente escalável. A fazenda pode dobrar ou triplicar o número de animais cadastrados, e o painel continuará abrindo em milissegundos.

5. Conclusão

Sistemas genéricos falham no agronegócio porque tentam tratar o peso de um boi como se fosse apenas o "estoque de uma loja". A pecuária é um organismo vivo, e seus indicadores, como o Ganho Médio Diário, exigem uma arquitetura desenhada para eles.

No fim das contas, bons sistemas resolvem problemas reais — o resto é exercício. Partir da dor do pecuarista para chegar à solução técnica de uma View avançada é o que diferencia código de prateleira de um software com propósito.

Quer analisar o meu código ou ver essa arquitetura rodando ao vivo?

💻 Acesse o código-fonte: Dom1ng0s/sistema_gado no GitHub
🚀 Teste o sistema: Deploy ativo via Docker na Oracle Cloud através do IP: http://163.176.171.60