verificar ou nao verificar se já existe um cadastro igual na tabela  XML
Índice dos Fóruns » Persistência: Hibernate, JPA, JDBC e outros
Autor Mensagem
v0olverine
Entusiasta Java

Membro desde: 26/05/2011 04:00:25
Mensagens: 16
Offline

bom dia a todos. Gostaria de saber se o procedimento correto de uma aplicacao web é:

quando o usuário clicar no botao "cadastrar", verificar antes de realizar o cadastro se algum registro igual a aquele que está para ser cadastrado já existe na tabela do BD ou se o ideal é que essa verificacao seja feita de alguma forma pelo proprio Banco de dados ou intao nao feita.
Se ouver alguma forma melhor de fazer essa tarefa, qual seria ? como fazer ?


meu medo é com essa verificacao ter uma grande perda de desempenho. Eu tenho uma tabela com 16 atributos, digamos que daqui a 3 anos essa tabela tenha 20 mil cadastros, se eu fizer:

select id from clientes where cli_nome = request.getParameter("nome") and cli_telefone = request.getParameter("tel") and cli_dt_cadastro = request.getParameter("ID_CLIENTE")
... assim nos 16 atributos e fizer a verificacao de modo que se essa exprecao retornar algum id existe registro igual se nao, nao existe.


fazendo assim em 20 mi ou maisl registros e depois cadastrando eu nao perderia muito desempenho ?



ViniGodoy
Moderador
[Avatar]

Membro desde: 11/12/2006 08:22:01
Mensagens: 25336
Localização: Curitiba/PR
Offline

Ou eu deixo o próprio banco se virar durante o insert com algum critério de unicidade indexado (como o CPF), ou eu não faço.

Mas nunca faço nenhum select em busca de um elemento duplicado.

@ViniGodoy - Lattes

Novo no fórum? Leia nosso How to.

Ponto V! - Desenvolvimento de Jogos Profissional - @Pontov - Facebook
Projeto Towel - Swing de uma forma inteligente (Novo lar do ObjectTableModel e do Auto-Filtro).

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso! Veja: http://www.guj.com.br/posts/list/15/199067.java#1001295
[WWW]
FernandoFranzini
JWizard
[Avatar]

Membro desde: 24/04/2009 12:58:16
Mensagens: 2067
Offline

Vc tem que escolher um ou um conjunto de campos deste cadastro que expresse a identidade unica do registro. E com isso, vc tem duas opções:

1. Verificar via programação antes do insert.
- Reduz a performance, pq vc vai executar + 1 select antes de cada insert. 500 usuários fazendo isso ao mesmo tempo são 1 mil acessos gastando datasource.
- Este é o tipo de caso de aumenta muito o datasource da aplicação.
- Unico ponto positivo aqui é que vc reduz a dependencia para seu provedor de SGDB.

2. Criar chaves únicas na tabela.
- Ao tentar gravar um registro com a chave ou grupo de chaves unicos, o banco de dados vai gerar uma exception indicando isso.
- O sistema deve tratar isso na camada de persistência, gerando uma mensagem adequada para o usuário.
- Cuidado com o tratamento da mensagem pq cada sgdb gerar um código diferente - use algo polimorfico, senão sua camada fica amarrada com um provedor de banco em especifico.
- Otima performance, pq vc faz 1 acesso ao banco só.
- Esta é a opção mais usada, uma que performance é uma das características mais importantes para o usuário final da aplicação.

Boa escolha amigo

This message was edited 1 time. Last update was at 26/05/2011 08:01:26


Fernando Franzini - Blog
[Email] [WWW]
Flavio machine
Virtual Machine Man
[Avatar]

Membro desde: 02/04/2008 13:24:56
Mensagens: 561
Offline

Da uma olhada no google por unique key, nossa vc ta usando servlets.
[Email] [MSN]
MichelSante
Debugger
[Avatar]

Membro desde: 04/05/2007 15:20:54
Mensagens: 52
Offline

Eu coloco a restrição no banco de dados.
Com isso a garantia é maior e a performance do sistema não cai.

Sds Michel
AbelBueno
GUJ Ranger

Membro desde: 04/08/2010 09:37:57
Mensagens: 924
Offline

Apesar de geralmente eu também não fazer a verificação antes, há casos em que acho justificado.

Ao criar um e-mail no hotmail, por exemplo, onde você já checa antes do submit se o e-mail já existe.

Esse tipo de retorno quase imediato facilita muito a vida do usuário.

O pior caso é, quando não valida antes, e ainda não guarda as informações que o usuário tinha digitado antes.
Não tem nada mais frustrante do que a mensagem "CPF já existe" e ter que preencher todo o cadastro novamente ppor conta disso.
v0olverine
Entusiasta Java

Membro desde: 26/05/2011 04:00:25
Mensagens: 16
Offline

Meu caso é umpoquinho complicado, em algumas tabelas até dá pra eu colocar o campo como unico e resolver o problema, tabela de clientes e funcionarios sao exemplos.
Agora eu estou fazendo um sistema para uma rede de lojas de moveis planejados e exite a tabela "orcamento" por exemplo que nao tem um campo que identifique um unico orcamento como o CPF de uma pessoa. Nesse caso oque devo fazer ? criar uma chave unica composta da juncao de todos os atributos da tabela "orcamento" ? como fazer isso ?
estou usando o postgreSQL

tabela orcamento:





FernandoFranzini
JWizard
[Avatar]

Membro desde: 24/04/2009 12:58:16
Mensagens: 2067
Offline

Vc "não tem" que fazer isso para todas as tabelas! Vc tem que fazer para aquelas que realmente precisam ser identificadas unicamente pelo programa. Lembrando que todos os registros de uma tabela tem que ser único e é por isso que usamos a PK.
Nesse caso seu de orçamento...eu vejo bem por cima que não precisa....um cliente poder pedir vários orçamentos...pq não?

Fernando Franzini - Blog
[Email] [WWW]
ViniGodoy
Moderador
[Avatar]

Membro desde: 11/12/2006 08:22:01
Mensagens: 25336
Localização: Curitiba/PR
Offline

- Reduz a performance, pq vc vai executar + 1 select antes de cada insert. 500 usuários fazendo isso ao mesmo tempo são 1 mil acessos gastando datasource.


Lembre-se que para fazer via programação o código deve, necessariamente, estar dentro de uma transação. Assim, você garante que um registro inválido não será inserido por outra pessoa entre o SELECT e o INSERT. Isso consome muito mais recursos do banco, pois não só exige uma consulta a mais, como também irá fazer LOCK na tabela, impedindo outros usuários de acessa-la até que a transação termine.

@ViniGodoy - Lattes

Novo no fórum? Leia nosso How to.

Ponto V! - Desenvolvimento de Jogos Profissional - @Pontov - Facebook
Projeto Towel - Swing de uma forma inteligente (Novo lar do ObjectTableModel e do Auto-Filtro).

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso! Veja: http://www.guj.com.br/posts/list/15/199067.java#1001295
[WWW]
 
Índice dos Fóruns » Persistência: Hibernate, JPA, JDBC e outros
Ir para:   
Powered by JForum 2.1.8 © JForum Team