Banco VS Código Back-End

Na boa mesmo, eu acho essa idéia de colocar regra de negócio em banco de dados terrível. Duvido muito que o hipotético ganho de desempenho compense o pesadelo que é dar manutenção em triggers e stored procedures. Ao colocar regras no banco de dados você já abre mão de: testes unitários e debugging. Na questão de desempenho, ao colocar regras no banco a sua única opção de escalar o banco é vertical, ou seja, você só consegue escalar o seu BD alocando mais CPU e memória, enquanto que uma aplicação Web pode ser escalada horizontalmente. Por fim, eu não tenho certeza (algúem confirme por favor), mas imagino que BDs em geral não paralelizam execuções de triggers. Assim, essas regras seriam executadas serialmente.

Enfim, talvez essa abordagem de centralizar regras de negócio em BD fizesse sentido na época de aplicações desktop que acessavam o BD diretamente. Nesse sentido, faz sentido deixar o BD fazer processamento para não travar a aplicação cliente. Já no universo Web e de cloud computing, penso que isso não faz sentido, pois as regras de negócio já são colocadas em um servidor. Nesse cenário, o servidor de aplicação pode ser escalado tanto horizontalmente quanto verticalmente, e com o advento de cloud computing, você pode alocar servidores virtuais otimizados para cada tarefa.

Muito obrigado pela opinião, ajudou muito mesmo

A questão de regras de negócios ficarem no banco de dados é sim válida, mas depende do banco de dados que você utiliza, por exemplo um MySQL não é um Oracle, o banco Oracle tem uma arquitetura muito robusta justamente para otimizar querys DDLs e etc, e também do tipo de regra. O mais certo a fazer em relação a isso é quais as regras que irão ficar no banco, através de views, triggers e etc. Por exemplo, se você possui uma consulta imutável, uma árvore por exemplo, sem dúvida nenhuma irá ser melhor por essa montagem da árvore no banco de dados, e irá onerar bem menos no sistema, agora como disse, tem que analisar bem qual regra irá ficar no banco.

Concordo com ambos: rmendes08 e rof20004 .

Depende de cada caso. Já trabalhei em projetos que toda a logica de negocio foi feita em procedures e functions Oracle, e a parte Java funcionava apenas como um frontend burro, que só chamava as procedures e retornava os resultados na tela. Escolhemos essa abordagem na epoca (uns 4 anos atras), pela expertise do time com banco de dados Oracle, e pela quantidade de cálculos que o sistema fazia. Era praticamente cálculos atrás de cálculos. Não imaginava fazendo tudo aquilo no Java, com vários laços de repetição dentro, com o Java 6/7 da época, sem streams e parallelStreams. Além disso o sistema era pra rodar na intranet, ou seja, não tinha muitos usuários simultaneos.

Colocando isso em questão, concordo com o rof20004 que depende de cada caso, e ao mesmo tempo concordo com o rmendes08, que um sistema assim não é nada escalável, e acredito que não trabalharia bem com um tanto razoável de usuários simultaneamente (20?).

O que discordo totalmente é já começar um sistema, pensando em migrar em outra linguagem depois. Primeiramente, essa migração não ocorrerá depois, Segundo, se ele ainda nem começou a ser desenvolvido, por que escolheram PHP para começar e não Java logo de cara? Já que ambos são iniciantes, começam já com a linguagem que vá atender os seus requisitos. Não estou falando pra começar com Java, mas sim escolher a melhor linguagem e começar por ela. Se ambos saibam mais PHP e ela atenda os requisitos do sistema, façam com ela e vão até o final.

Você pode pesquisar no Github por projetos que utilizam a mesma plataforma (LAMP) e ver como programadores mais experientes fazem.

Acredito que todas as opiniões foram muito importantes.

As regras de negócio residem na aplicação, se você esta fazendo uma aplicação Oracle, é natural que as regras fiquem no banco, porque Oracle é um banco de dados. Se você esta fazendo uma aplicação Java, ou PHP, a regra de negócio vai rodar no processo que roda a aplicação Java, que é um processo diferente do banco de dados.

Parece que a questão não é onde vai residir a regra de negócio, ela sempre reside na aplicação, a questão é que aplicação você esta criando e, se ela reside num processo diferente do banco, como faz pra mover os dados até sua aplicação.

O que ocorria antigamente (até hoje em alguns casos), que o computador que era o servidor de banco de dados era mais robusto do que as máquinas cliente, logo delegava-se tudo para o banco de dados.

Se você decidir usar algo da regra de negócio no banco de dados, deve deixar bem documentado e deve ser coisas simples a ponto de ser fácil entender e dar manutenção.

Eu recomendo você já começar o sistema na linguagem definitiva lembrando que ambas linguagens tem vários frameworks/ferramentas que podem ou não atender as suas necessidades.
Podere isso na escolha das tecnologias utilizadas.

E também manter a regra de negócio (ou a maioria dela) na aplicação pelos motivos já citados pelos colegas.