Eu acredito que as regras de negócio devem estar no código da aplicação e não no banco de dados. Está certo esse ponto de vista? As Stored Procedures devem ser evitadas?
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
Solucionado
Eu acredito que as regras de negócio devem estar no código da aplicação e não no banco de dados. Está certo esse ponto de vista? As Stored Procedures devem ser evitadas?
Oi Roberto, tudo bem?
Eu concordo contigo. As stored procedures eram muito usadas e praticamente obrigatórias para qualquer desenvolvedor, uns 15 anos atrás. Isso porque o paradigma era "database first", ou seja, o banco de dados relacional era o ponto central de toda aplicação, e acabava concentrando boa parte das regras de negócio. Por isso, muitas vezes as stored procedures e triggers centralizavam boa parte dessas regras. Uma das vantagens desse processo, era poder realizar "hotfix" sem alterar uma linha de código da aplicação! E o preço disso era a possível quebra de regras da aplicação, já que não se aplicam testes de unidade no banco de dados. Assim, o banco de dados acumulava funções como Data Access Layer + Business Logic Layer enquanto a aplicação em si funcionava como "interface do usuário". Porém, com o passar dos anos, apareceram novas formas de persistência de dados: fontes de dados heterogêneas (SQL Server + MySQL + Oracle), NoSQL (MongoDB, Redis, etc.), o que tornou proibitivo incluir qualquer regra dentro de uma procedure de banco de dados. Por isso, atualmente as regras precisam ficar no código da aplicação, o que permite que a aplicação seja desacoplada de um banco de dados específico: você pode estar usando SQL Server hoje, mas eventualmente poderá mudar para MySQL, MongoDB ou SQLite. E o mais importante, as regras de negócio no código e não no BD permitem a testabilidade, através de testes de unidade automatizados e testes funcionais, prevenindo contra possíveis falhas na aplicação.