Aí é que está, vai do “gosto” de cada um, geralmente a pessoa prefere aquilo com que está acostumado…
Comentando sobre alguns itens que vc citou:
" - se sua aplicação mudar de banco de dados você perde toda as regras de negócios"
Eu particularmente uso sempre ORACLE em todos os meus projetos. Ou seja, posso
considerar o inverso: posso mudar todo o front-end da aplicação, sem perder a regra de negócio.
“- quando você desenvolve stored procedures, triggers e etc, você está fugindo do mundo OO (que teoricamente é o que você está acostumado a programar em Java) e utiliza o modelo relacional dos banco de dados”
Tudo bem, não vejo nenhum problema nisso…
" - o programador além de saber Java, deve também conhecer bem o banco de dados."
Prefiro dividir duas equipes: uma trabalhar nas telas, interface, front-end em geral;
e a outra equipe apenas com programação PL/SQL (no caso do Oracle).
“- debugar uma aplicação é quase que um tiro no pé”
No Oracle eu debugo stored procedures facilmente, sem problemas.
Mas enfim, não quero criar nenhum tipo de discussão entre as preferências de um e de outro…
Apenas prefiro esse modelo pois a performance é, de fato, melhor quando se tem
um banco de dados confiável e, obviamente, um servidor com hardware suficiente pra isso.
Até desviamos um pouco a pergunta do início do tópico…
Ele perguntou sobre as restrições (constraints), se devem ficar na aplicação
ou no banco de dados. Isto eu posso afirmar, com certeza, que deve obrigatoriamente
existir no banco de dados. E adicionalmente pode/deve ser tratado na
aplicação também, ou seja, validando dados na tela antes de serem enviados pro banco de dados.