Parabéns pelo post! E obrigado por compartilhar. É legal ver outros se aventurando na da programação dentro do banco de dados.

PL/SQL é uma ferramenta incrível para quem realmente quer dominar a arte de programação. E não se trata só de PL/SQL no Oracle, mas também do pgSQL no Postgres, inclusive com suporte à JavaScript, ou até funções nativas em C para o SQLite.

Programar direto no banco é poderoso, eficiente, e, sinceramente, muito mais divertido! E tem muita gente por aí ainda discutindo qual ORM é o melhor... Hahaha, mal sabem eles o que estão perdendo!

Um abraço e bons estudos!

hyperdevhá 2 meses

Porém colocar regra de negócios no banco de dados é de uma burrice sem tamanho, gerando acoplamento desnecessário.

Outro ponto é o fato de ser Oracle, um banco que se perdeu no tempo, deixando muito a desejar. O PostgreSQL hoje em dia é muito superior ao Oracle em vários aspectos.

clacerdahá 2 meses
Burrice é duplicar as regras de negócios ;)
rnpr4541há 2 meses
Se não colocar a regra de negócio no banco de dados, como consegue garantir a qualidade/integridade dos dados, se estes forem alterados fora da aplicação. No caso Oracle se eu aceder aos dados a partir do cliente sqlplus por exemplo e modificar dados, como garantir a consistência? Quanto ao Oracle se ter perdido no tempo, não me parece que tenha estado com atenção às versões que têm sido lançadas... podemos ter queixas do custo, mas de funcionalidades não vejo atraso nenhum :-)
JohnDoeZeroToLefthá 2 meses
Em seu contexto onde deve ir a regra de negócio? No seu framework/orm hypado do momento, isso não seria uma burrice sem tamanho?
gabrielTapeshá 2 meses
Quem trata de regra de negócio é o backend, o ORM só deve validar os dados e se comunicar com o Banco, q por sua vez só deve armazenar e recuperar os dados. Pra que serve o backend na tua visão já que quer fazer tudo direto no banco de dados?
JohnDoeZeroToLefthá 2 meses
Em ciência da computação quando finalizei lá em 2001 a regra de negócio era inserida no db, desde então trago isso em todo meu desenvolvimento client/server independente de backend/middleware/frontend. Processamento muito mais rápido quando o próprio db executa a regra em seu core, do que depender de um backend enviar todas transações, além de você minimizar quantidade de código do backend. Costumo deixar o backend principalmente para crud e consumo de api, o máximo que eu puder fazer de regras no db eu faço!
gabrielTapeshá 2 meses
Isso é algo pessoal seu, não tem nada a ver com ser melhor ou pior. Não adianta sair criticando meio mundo só pq fazem as coisas diferente do que era feito em 2001, as coisas mudam, evoluem e se transformam, tecnologia é assim. Em 2001 Fortran era mais utilizado do que Python para analise de dados, hoje a maioria nem sabe o que é Fortran.
JohnDoeZeroToLefthá 2 meses
Quem criticou foi quem falou que era uma burrice sem tamanho, apenas coloquei meu ponto de vista. Fortran 1960 meu amigo, 2001 era java e continua sendo... Qual o seu ponto de vista?
gabrielTapeshá 2 meses
Fortran tinha bastante relevância nos anos 90 e início dos anos 2000, mas nunca chegou a ser uma linguagem comercial como Java é até hoje. O principal trabalho feito em Fortran é a Lapack, q foi escrita em Fortran 77 e é usada por debaixo dos panos em qualquer sistema que envolva o mínimo de Álgebra Linear, utilizando o frontend Blas. A questão de regra de negócio é mínimamente de implementação, uns utilizam no banco, outros no backend, outros delegam para o ORM e também existem os boçais que ligam o frontend diretamente no Banco de Dados sem nenhum tipo de validação. Todos tem problemas e todos tem alguma vantagem, no meu ponto de vista programação é algo social, você usa o que o seu time decidir usar, gostando ou não.