Colocar alguma regra no banco?

Olá!

Eu acredito que validações devam ser colocadas em ambos os lados, até porque validações no SGBD evitam as inconsistências causadas por eventuais "marretadas". O ponto é que existem certas coisas que acredito que fiquem melhores no banco de dados como por exemplo a auditoria. Com triggers esse trabalho é muito simplificado, além do ganho de performance (não necessita fazer IO a cada inserção), tem a questão da grande segurança dos SGBDs, etc...

O que vocês acham?

Abraços

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Para esse caso eu não implementaria lock algum. O Cliente não pode estar em dois lugares ao mesmo tempo, e mesmo que estivesse utilizando dois caixas ao mesmo tempo, é capaz das duas vendas serem válidas.

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Link_pg wrote:Olá!

Eu acredito que validações devam ser colocadas em ambos os lados, até porque validações no SGBD evitam as inconsistências causadas por eventuais "marretadas". O ponto é que existem certas coisas que acredito que fiquem melhores no banco de dados como por exemplo a auditoria. Com triggers esse trabalho é muito simplificado, além do ganho de performance (não necessita fazer IO a cada inserção), tem a questão da grande segurança dos SGBDs, etc...

O que vocês acham?

Abraços

Na minha opinião as validações devem ser colacadas nos dois lados também. Eu acho que uma coisa que pode justificar colocar as regras em procedures, funcitions etc é o fato de você dar a permissão - grant - para alguns usuários apenas

Mas acho que talvez isso também seja possível via código, alguem sabe?

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Rafael Nunes wrote:Mas você tem mesmo essa necessidade? Qual o problema de você verificar a consistência antes de realizar a venda?

Tem razão, acho que exagerei na preocupação.

Andre Fonseca wrote:o fato de você dar a permissão - grant - para alguns usuários apenas

Mas acho que talvez isso também seja possível via código, alguem sabe?

Hoje, apesar de implementar muita coisa no banco de dados, eu implemento usuários e controle de permissões manualmente, e verifico tudo na aplicação.
Mas não trabalho com permissões a nível de procedures e tabelas, nunca tive necessidade disso. É mais algo tipo "Permissão para baixar contas a receber".

Bruno Laturner wrote:Para esse caso eu não implementaria lock algum. O Cliente não pode estar em dois lugares ao mesmo tempo, e mesmo que estivesse utilizando dois caixas ao mesmo tempo, é capaz das duas vendas serem válidas.

Concordo! A única coisa que acho que poderia acontecer (acho isso bem difícil, ao menos nunca vi) é o setor de crédito bloquear o cliente justamente alguns minutos antes do cliente chegar no caixa.

Link_pg wrote:Eu acredito que validações devam ser colocadas em ambos os lados, até porque validações no SGBD evitam as inconsistências causadas por eventuais "marretadas". O ponto é que existem certas coisas que acredito que fiquem melhores no banco de dados como por exemplo a auditoria. Com triggers esse trabalho é muito simplificado, além do ganho de performance (não necessita fazer IO a cada inserção), tem a questão da grande segurança dos SGBDs, etc...

A minha opinião sobre isto é que, colocar código no banco ou não tem a ver com estratégia. Por exemplo, uma empresa que produz e vende software colocar tudo ou boa parte do código no banco de dados poderá encontrar situações bem ruins, caso um cliente que utilize um banco de dados que não esteja previsto no sistema. Quando isto acontece, geralmente passa um monte de desenvolvedores virando noites codificando procedures / functions / triggers para o "novo" banco.

Se o sistema em questão for utilizado apenas dentro da organização acho que fica mais tranquilo, desde que vc possua uma equipe de banco / dba comprometidos com os resultados. Caso contrario, ocorre muitas brigas ("tretas"). Não é em todos os lugares que vc pode ficar "pondo as mãos" no banco de dados, tem que solicitar ao dba para ser executado. E muitas vezes eles fazem isto quando eles acharem melhor, ou seja, vc pode ficar parado esperando enquanto o seu cronograma "vai pro brejo".

flws

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3371 Offline

"

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

O que estou achando interessante da discussão é que quando eu vi a pergunta achei que ia encontrar um monte de gente radicalmente contra colocar alguma coisa no banco, mesmo que seja uma validação que já tenha na aplicação.

Bom, particularmente, eu estou bem tentado a tirar o máximo possível do banco.
Mas claro, sem deixar de manter a mente aberta para eventuais exceções

Seria interessante voce dar um olhada em ferramentas de rules repository.

fantomas wrote:A minha opinião sobre isto é que, colocar código no banco ou não tem a ver com estratégia. Por exemplo, uma empresa que produz e vende software colocar tudo ou boa parte do código no banco de dados poderá encontrar situações bem ruins, caso um cliente que utilize um banco de dados que não esteja previsto no sistema. Quando isto acontece, geralmente passa um monte de desenvolvedores virando noites codificando procedures / functions / triggers para o "novo" banco.

Claro que se você desenvolve um produto que não se sabe em qual SGBD (ou qualquer outra maneira de persistir) vai rodar, você não vai deixar dependente daquele SGBD específico. Já vi empresas que desenvolvem aplicativos que são independentes de banco de dados, mas daí é meio impossível de cobrir 100% dos casos.

fantomas wrote:Se o sistema em questão for utilizado apenas dentro da organização acho que fica mais tranquilo, desde que vc possua uma equipe de banco / dba comprometidos com os resultados. Caso contrario, ocorre muitas brigas ("tretas"). Não é em todos os lugares que vc pode ficar "pondo as mãos" no banco de dados, tem que solicitar ao dba para ser executado. E muitas vezes eles fazem isto quando eles acharem melhor, ou seja, vc pode ficar parado esperando enquanto o seu cronograma "vai pro brejo

Por exemplo, aqui na empresa desenvolvemos vários sistemas pra um grande player de telecom. Usamos o Oracle como persistência padrão faz uns 10 anos. Eu duvido que eles vão migrar isso um dia e se migrarem, é algo que vai perdurar mais uns 10 anos. Como você disse, nesse caso acho que até vale a pena utilizar os recursos específicos do SGBD, pois eles são infinitamente (tá, não tão infinitamente aheheauea) mais performáticos, além de oferecer uma segurança maior (pois o Oracle, por exemplo, já está no mercado há muito tempo e é maduro o suficiente para ser mais seguro do que código feito por nós, meros programadores de consultorias)

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

Rafael Nunes wrote:

magnomp wrote:
Eu estou muito acostumado com client/server, onde é apenas o sgbd no servidor e os clientes nas estações... Removendo tudo do banco, você precisará implementar um servidor de aplicações que vai receber todo o acesso das estações e validar os dados, correto? Neste caso, qual seria a melhor forma de implementar isso?

Essa é a idéia, agora o teu sistema não está mais na máquina do cliente, o cliente tera na sua máquina somente o que precisa para visualizar o sistema, o sistema em si com suas regras e etc estão em um servidor intermediário.

Saíndo um pouco do assunto original da thread, mas acho que ainda dá pra perguntar aqui mesmo:
Considerando um sistema que estou começando, que a principio vai em desktop, mas com um módulo via web, qual a melhor tecnologia para implementar este servidor?

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1693 Online

Sou a favor de deixar a lógica de negócios completamente independente do SGBD, porém, se possível, implementar validações TAMBÉM no SGBD, pra garantir uma segurança a mais.

Abraços.

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

magnomp wrote:Saíndo um pouco do assunto original da thread, mas acho que ainda dá pra perguntar aqui mesmo:
Considerando um sistema que estou começando, que a principio vai em desktop, mas com um módulo via web, qual a melhor tecnologia para implementar este servidor?

Respondendo à minha própria pergunta, pensei no seguinte:
Coloco todo o domain (as interfaces dos repositórios junto...) em um jar, a ser utilizado tanto no servidor quanto no cliente.
No servidor tenho implementações dos repoistórios acessando os dados via hibernate, jdbc ou o que quer que seja..
E no cliente tenho implementações dos repositórios que se comunicam via rede com os repositórios localizados no servidor..
Assim, no lado do cliente, a coisa ficará bem transparente no lado cliente. Assim, no desktop vou ter minha aplicação acessando diretamente esse "RemoteRepository", e na parte web ele seria acessado pelos meus servlets.

Alguem aqui vê algum inconveniente nesta abordagem?

Notícias, artigos e o maior fórum brasileiro sobre Java