Meus 2 cents,

Pela minha experiencia, a resposta é: "depende" (pois é, não ajudou nada)

Comentário sobre dependência de bancos de dados em aplicações modernas

Sua pergunta é muito pertinente e reflete uma discussão que está presente no desenvolvimento de software há anos. A prática de concentrar lógica de negócio em procedures, funções e views é uma abordagem que evoluiu ao longo do tempo, com diferentes práticas sendo adotadas dependendo do contexto.

Pontos-chave para analisar essa situação:

1. Contexto de sistemas legados: É comum em aplicações mais antigas encontrarmos grande parte da lógica implementada no banco de dados. Isso ocorre por questões históricas de desempenho (quando a capacidade de processamento era mais limitada) ou porque essa era a abordagem dominante no momento da criação desses sistemas.

2. Vantagens da lógica no banco:

   • Desempenho: Realmente, como você mencionou, operações que envolvem grandes volumes de dados se beneficiam muito de serem processadas diretamente no banco, evitando a transferência massiva de dados pela rede.

   • Atomicidade e consistência: Procedimentos armazenados garantem transações atômicas e integridade referencial.

   • Redução de duplicação: A mesma lógica pode ser reutilizada por múltiplos sistemas clientes.

3. Tendências modernas:

   • Separação de responsabilidades: As arquiteturas modernas tendem a seguir o princípio da responsabilidade única, com a camada de negócios separada da camada de dados.

   • Umassive de ORMs: No ecossistema .NET, o Entity Framework e outros ORMs facilitaram a abstração do SQL, permitindo que a lógica de negócio fique no código da aplicação.

   • Testabilidade: Code-first e testes untários facilitam com que a lógica de negócio seja testada de forma independente do banco.

   • Padrões modernos: Arquiteturas como CQRS (Command Query Responsibility Segregation) muitas vezes separam leitura (queries) e escrita (commands), com queries sendo otimizadas no banco.

4. Quando ainda é válido manter lógica no banco:

   • Operações complexas que envolvem múltiplas tabelas e grandes volumes de dados
   • Lógica para geração de relatórios complexos
   • Processos em lote (batch)
   • Auditoria e triggers para manter consistência
   • Views para abstrair consultas complexas que são frequentemente reutilizadas

Conclusão

Não se trata mais de uma prática "descontinuada", mas sim de uma mudança de paradigma: os sistemas mais modernos tendem a colocar menos lógica no banco e mais na camada de aplicação, mantendo apenas os casos onde isso realmente traz benefícios claros.

Se você está trabalhando com sistemas legados, é natural encontrar essa concentração de lógica no banco. No entanto, ao desenvolver novos sistemas, é comum encontrar uma abordagem mais balanceada, onde:

• A camada de negócios fica na aplicação
• O banco é responsável pela persistência e integridade dos dados
• Procedures e funções são usados estrategicamente para casos específicos de performance ou complexidade

A verdade é que a melhor abordagem depende sempre do contexto do projeto, das equipes envolvidas e das necessidades específicas da aplicação.

Saude e Sucesso !