Pessoal gostaria de saber se há alguma diferença de fazer modelagem de um banco de dados para WEB e para uma simples aplicação client/server
No caso, todas as regras estarão numa camada java, o que estou perguntando se é necesário ter constraints, triggers
Onde posso muscar mais sobre o assunto
A modelagem de uma base de dados baseada em web é básicamente a mesma para uma aplicação cliente / servidor. Em relação à lógica, esta deve estar contida na camada de Controle (padrão MVC). Nesta camada estão inseridas as classes que gerenciam as regras de negócios da sua aplicação.
Um abraço.
Na minha humilde opinião, o mais seguro é fazer o máximo possível no banco de dados (seja client-server, seja Web).
Constraints, OBRIGATORIAMENTE.
Eu particularmente deixo todas as regras de negócio no banco de dados, em stored proceduers, triggers, functions, etc…
Eca…
[quote=RaulCarlin][quote=MiltonBastos ]
…
[/quote]
Eca…[/quote]
???
Só uma brincadeira, é que não gosto desse tipo de coisa…
Certo, mas… não gosta por que?? rs…
A performance da aplicação é consideravelmente melhor
com essa arquitetura…
Ai começa a velha discussão:
e por ai vai…
Mas cada um tem um gosto. Eu particularmente não gosto de stored procedure (apenas 1 vez na vida precisei trabalhar com stored procedure em um sistema legado que utilizava Stored Procedure), hoje eu prefiro utilizar JPA/Hibernate e ser feliz 
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.
e se um dia você precisar trabalhar em outro local que não usa oracle?
e precise integrar transações em dois bancos diferentes ao mesmo tempo?
[quote=marcushlm]
e se um dia você precisar trabalhar em outro local que não usa oracle?
e precise integrar transações em dois bancos diferentes ao mesmo tempo?[/quote]
Já trabalhei em ambientes com vários bancos diferentes (Oracle, SQL Server, DB2,
até Firebird… rs…) e também com várias linguagens (JSP, Delphi, até .NET… rs…)
Não estou dizendo que DEVE ser feito SEMPRE dessa maneira,
e sim que essa é a maneira como eu PREFIRO (entre tantas outras que
já tive de trabalhar), principalmente analisando pelo lado do cliente, pois
pra ele não importa COMO vc desenvolveu, e sim o desempenho, a performance
da aplicação.
[quote=MiltonBastos][quote=marcushlm]
e se um dia você precisar trabalhar em outro local que não usa oracle?
e precise integrar transações em dois bancos diferentes ao mesmo tempo?[/quote]
Já trabalhei em ambientes com vários bancos diferentes (Oracle, SQL Server, DB2,
até Firebird… rs…) e também com várias linguagens (JSP, Delphi, até .NET… rs…)
Não estou dizendo que DEVE ser feito SEMPRE dessa maneira,
e sim que essa é a maneira como eu PREFIRO (entre tantas outras que
já tive de trabalhar), principalmente analisando pelo lado do cliente, pois
pra ele não importa COMO vc desenvolveu, e sim o desempenho, a performance
da aplicação.
[/quote]
argh, nem me fale de firebird hehehehehe
desempenho é importante mas manutenabilidade também 
[quote=marcushlm]
argh, nem me fale de firebird hehehehehe
desempenho é importante mas manutenabilidade também [/quote]
Firebird eu nem considero como banco de dados… rs…
Mas, fazer o que, as vezes somos obrigados a trabalhar com coisas
que não são as melhores do mundo… rs…
Sobre a manutenção, eu também prefiro a nível de banco de dados.
Caso necessite correção de algum bug, ou mesmo alguma melhoria,
é possível fazê-la apenas rodando um script SQL na base de dados.
Fácil, rápido, e sem traumas.
Você muda o front-end de uma aplicação Java facilmente também sem precisar programar nada nas classes de negócio, e ainda muda facilmente de banco de dados também(em questão de minutos)…
To que nem o ManchesteR, feliz com JPA/Hibernate…
Você tá quase me convencendo desse mundo perfeito onde é tudo simples e rápido vendendo sua alma pro banco de dados… hehehe
Falando sério, para atualizar em Java você pode fazer um simples deploy fácil, rápido e sem traumas…
Não adianta, realmente gosto é gosto… podemos ficar horas discutindo que nada vai mudar…
Minha experiência com regra de negócio no banco de dados são as piores possíveis. E nem digo por ficar preso ao banco, isso é o de menos. Digo pela dificuldade de manutenção e teste automatizados.
[]'s
Rodrigo Auler
Além do gosto, é necessário também verificar em qual modelo você é mais produtivo.
Se você domina trabalhar no banco e é mais produtivo no mesmo, excelente. Eu por exemplo, no banco que trabalho no momento (DB2), só sei fazer as operações básicas de SELECT, INSERT, UPDATE,DELETE, ou seja, eu desenvolvendo minhas regras de negócio em Java, eu sou mais produtivo.