Colocar alguma regra no banco?

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

Estou tentando me afastar do mundo procedural + relacional que estou acostumado e me aproximar mais da POO...

Normalmente eu uso e abuso de not nulls, checks, triggers e exceptions no BD para garantir a integridade dos dados, mas agora pergunto: Estas validações devem continuar a serem feitas no banco de dados? Ou devem ser tratadas em objetos na minha aplicação?

Fiz essa mesma pergunta em um forum gringo, e a resposta que tive foi que se dados inválidos conseguirem chegar até o banco de dados, é sinal de que houve uma falha na aplicação, que deveria ter validado os dados antes de persistir. Então no final das contas, o banco de dados seria um mero repositorio de dados sem qualquer inteligencia.
A principio me pareceu chocante, pois vai contra tudo que eu tinha em mente, mas pensando bem agora posso ver que faz bastante sentido. Vocês seguem esta linha tambem?

Fiz algumas pesquisas aqui mesmo, e cheguei até o livro de Domain Driven Design do Eric Evans. Já está na minha lista para ser lido. Recomendam algum material?

Sim, o único momento que eu particularmente tenho deixado qualquer tipo de inteligência no Banco de Dados, é quando preciso fazer processos em lote(exmplo: Inserir 100 mil registros por hora/dia/minuto). Que eu delego para uma Stored Procedure. Em qualquer outro cenário não vejo e não tive necessidade nenhuma de deixar qualquer inteligência no banco além de guardar dados.

Recomendação de livros:
http://www.guj.com.br/posts/list/36319.java
http://www.guj.com.br/posts/list/16282.java

Costumo colocar regras simples.
PKs, FKs e UKs, nada muito complexo não simplemente para garantir a integridade básica do banco.
Mas a maioria da inforamção é checada pela aplicação.

[]'s

boa tarde... eu trabalho com validação em banco nos casos que tenho mais de uma aplicação acessando o mesmo. Dessa forma viso garantir que os dados estarao sempre coerentes independente da aplicação que esta acessando/ inserindo/ editando as informaçoes do sistema. Caso alguma dessas aplicaçoes tente fazer algo contra as normas tenho como ultima camada o banco validando. Pode nao ser a melhor tecnica, nem a mais "bonita", mas o que me importa é a informação final.

[]´s

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

Em qualquer outro cenário não vejo e não tive necessidade nenhuma de deixar qualquer inteligência no banco além de guardar dados.

Isso inclui not nulls, checks e foreign keys? Nem isso vc deixa no banco?

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?

Costumo colocar regras simples.
PKs, FKs e UKs, nada muito complexo não simplemente para garantir a integridade básica do banco.

Foi o que pensei logo de inicio, mas aí vem a questão: Como definir o que fica no banco e o que vai pra aplicação?
No final cheguei à conclusão que não tem porque dividir: Se é tudo necessário para garantir a integridade dos dados, então coloca tudo em um só lugar, ou no SGBD ou na aplicação. O que acha?

Eu acredito que o basico de validação sempre é bom ter no banco.
Mas eu prefiro muito mais validar a auto nivel, muito mais pratico de se dar manutenção tbm.
O ideal seria ter validação a todo o lado, tanto no BD quanto na aplicação, assim vc garante que seus dados serão integros.

[]'s

This message was edited 1 time. Last update was at 21/07/2009 13:40:13

magnomp wrote:Isso inclui not nulls, checks e foreign keys? Nem isso vc deixa no banco?

Na maior parte dos casos eu utilizo algum framework ORM(HIbernate/TopLink) e eles já fazem isso para mim, conforme a regra que crio em minhas entidades/classes eles refletem para o banco de dados.
Quando não utilizo-os, alguma regras como not null, fk, pk eu acabo deixando em ambos os lados(aplicação e banco)

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.

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

Falando em ORM, é recomendavel que eu encapsule o hibernate (ou qualquer que seja o mecanismo de persistencia utilizado) de forma que só uma parte bem especifica da aplicação tenha acesso direto a ele? Digo isso pois imagino que qualquer um poderia utilizar o hibernate para executar uma query diretamente nele, sem verificar a validade dos dados, resultando na quebra da integridade das minhas informações.

Algo tipo:
GerenciadorDeVendas.registrarVenda(venda); { Aqui, antes de gravar a venda, verificará o status do cliente para ver se ele não está bloqueado }

JavaGuru Membro desde: 21/08/2007 01:43:38 Mensagens: 244 Offline

FK, PK, UK e campos not null sempre deixo com o BD.

Agora a regra de negocio deixo na aplicação. Mas sempre é bom utilizar o bom senso, caso tenho um processo batch gigantes prefiro deixar numa procedure no banco de dados e iniciar pela aplicação.

Trabalhei muito tempo com oracle e na outra empresa toda regra de negocio tratavamos com triggers, procedures e function (PL/SQL). Eu acho que tem os prós e contras, trabalhando dessa forma deixamos a aplicação totalmente amarrada na aplicação. Mas como sempre dizem isso depende muito do projetos ...

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

Eu sempre defendi que na maioria dos casos não se deve priorizar uma ou outra arquitetura pelo fato de facilitar a migração de um banco de dados porque muitas vezes essa facilidade nunca será usada.

Mas a pouco tempo atras, li um post em um blog sobre isso que me fez mudar totalmente de ideia: É importante que a aplicação seja independente de banco de dados mesmo que vc nunca precise trocar o sgbd X pelo Y, para que você possa substituir a persistencia para o sgbd X por uma persistencia "falsa", durante testes automatizados.

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

"

JavaGuru Membro desde: 21/08/2007 01:43:38 Mensagens: 244 Offline

Realmente esse seria o melhor do mundo não deixar aplicaçao presa ao banco de dados. Por mais que temos as ferramentas como Hibernate/JPA, eu acho dificil pensar dessa forma como deixar uma aplicação muti/banco, pois dependendo da complexidade da aplicaçao temos que usar os recursos do bancos de dados querys complexas a melhor opçao é views.

j

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.

Poderia me dar uma idéia de como implementar algo para gerenciar o acesso simultâneo de várias estações que podem interferir uma com a outra?
Tipo, imagine duas estações: "A" e "B". "A" carregou um Cliente e está registrando uma venda para ele, mas nisso "B" tambem acessou o mesmo cliente e o marcou como "Bloqueado", um status que deveria impedir a operação que "A" está fazendo.
Como a validação não estará no banco de dados, se eu não for capaz de verificar isso adequadamente na hora de gravar a venda, vou estar gerando uma inconsistencia nos dados.

Se eu fizer algo assim:

Mesmo que eu dê um "refresh" no cliente naquele momento, ainda pode ocorrer o problema.

Será que eu deveria trabalhar com locks aí?
Tipo:

É o caminho correto?

'Correto' é meio relativo.

Uma opção é trabalhar com blocos sincronizados sim.

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

Se for possível, eu preferiria evitar a complexidade desnecessária de trabalhar com os blocos sincronizados.

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