Dados e persistência
Oracle corporativo é a realidade da maior parte do que eu mantenho. Trabalhar bem nele, respeitando schema legado, transação e volume, determina mais o meu dia do que qualquer outra tecnologia da minha lista.
Presença
| Banco | Repositórios |
|---|---|
| Oracle | 56% |
| MongoDB | 6% |
| PostgreSQL | 4% |
| TimescaleDB | 1 sistema, série temporal sobre PostgreSQL |
| Acesso | Repositórios |
|---|---|
| Entity Framework Core | 54% |
| Dapper | 21% |
Oracle, e por que ele vem primeiro
Currículo costuma listar banco de dados no fim, em ordem alfabética, como se fosse detalhe de implementação. No meu caso é o contrário: a maior restrição de projeto do parque é o Oracle corporativo compartilhado. O schema não é meu, a tabela que eu leio outro sistema também lê, e mudança de coluna precisa de combinação entre times.
O que isso exige na prática:
- Trabalhar em schema legado e compartilhado, respeitando quem mais depende dele
- Escrever consulta analítica com volume sem trazer a tabela para a memória da aplicação
- Ler plano de execução e corrigir consulta ruim
- Cuidar de transação que atravessa mais de uma tabela, com rollback correto
- Manter compatibilidade de banco durante migração de versão da aplicação
- Conviver com múltiplos schemas de domínios diferentes na mesma instância
EF Core e Dapper, no mesmo projeto
Escrita passa pelo ORM, porque ali o modelo de domínio manda na persistência: rastreamento de mudança, unidade de trabalho e transição de estado da entidade ganham do SQL escrito à mão. Leitura pesada passa por SQL direto, porque ali a consulta é o produto e precisa ser revisável linha a linha — relatório, painel, extração para conciliação, ou consulta que precisa de um recurso do Oracle que o ORM não expõe bem.
Ter os dois no mesmo projeto é escolher a ferramenta por caso, não por doutrina.
O que eu cuido no EF Core: consulta que gera N+1 sem avisar, rastreamento desligado no que é só leitura, migração de schema em base compartilhada onde nem sempre a aplicação pode alterar a tabela, e mapeamento de objeto de valor para coluna existente de schema legado.
MongoDB e PostgreSQL
São os bancos do que nasce agora, num parque onde o Oracle domina o legado.
MongoDB quando o documento é naturalmente sem esquema fixo: payload de integração que varia por parceiro, registro de log de processamento, dado cuja forma o fornecedor muda sem avisar. A armadilha que eu evito é usá-lo como banco relacional disfarçado — se a consulta precisa de junção, o dado estava no banco errado.
PostgreSQL quando o sistema é novo e não tem obrigação de conviver com o schema corporativo.
TimescaleDB, para série temporal
Extensão do PostgreSQL usada no Monitoramento industrial. Máquina em chão de fábrica emite evento continuamente, e guardar isso em tabela relacional comum funciona por algumas semanas antes de a consulta de painel começar a demorar: o volume cresce numa dimensão só, o tempo, e o índice tradicional não ajuda tanto quanto parece.
O que a extensão acrescenta, mantendo SQL e ferramental: hypertable com particionamento automático por tempo, política de retenção e agregação contínua. Foi o que permitiu o painel responder rápido sobre janela longa.
Onde apliquei
Pagamentos e antifraude · Monitoramento industrial · Comissionamento · Gestão documental · Integrações corporativas
O que eu ainda não fiz
Não sou DBA. Leio plano de execução e sei corrigir consulta ruim, mas tuning fino de instância, particionamento e replicação são território de outra pessoa. Não trabalhei com data warehouse próprio nem com pipeline de dados em escala analítica. Em TimescaleDB tenho um sistema só, e recente: sei modelar hypertable, retenção e agregação contínua, sem quilometragem de operação em escala.