[firebase-br] RES: Otimização de Transação

[Sandro Souza]

Bom dia/tarde Luis.

Grande Luis, interessante o seu caso, pois aí é realmente uma necessidade
mesmo.

Eu confesso que também costumo usar essa técnica do "MAX(codigo) + 1" para
gerar os próximos códigos.

Eu poderia utilizar geradores/sequences, mas como os valores lidos dos
geradores são incrementados em uma transação separada, e não são afetados
por um rollback na transação principal, isso por si só já geraria uma
"brecha" de código quando cancelarmos a transação atual e tentarmos
novamente para obter o novo código. Acho que você optou não usar pelo mesmo
movito, não foi?

Temos ainda a questão da criação das brechas de código quando excluimos um
ou mais registros. Não sei se esse também é o seu caso.

No que depender de mim, pode contar para chegarmos a um algoritmo mais
otimizado que atenda a esse tipo de necessidade. :D

2009/12/3 Luis <luisfirevb em gmail.com>

> Sandro bom dia.
>
> No meu caso isso não é perfumaria, muito pelo contrário. Porém minha
> necessidade é um pouco diferente. Não se trata de reaproveitamento dos
> números ou preenchimento de lacunas, mas não deixar a sequência se quebrar
> explico.
>
> Trabalho com auditoria de normas técnicas e a gestão das mesmas implica em
> rastreabilidade. Sendo assim os controles realizados, devem
> obrigatoriamente
> seguir uma sequência sem lacunas, pois se houver lacunas pode ser assumido
> que houve exclusão de uma informação importante para ser ocultada, mesmo
> que
> manualmente no banco. Assim essa numeração não pode "falhar". Exemplo: Um
> dos controles é reclamação de clientes, essas reclamações devem ser
> cadastradas e tem seu processo normalmente, com apuração, ações, aprovação
> e
> verificação final de sua solução. Se houver uma falha um auditor pode
> entender como exclusão de informação crítica que compromete o sistema de
> controle e não certificar a empresa.
>
> Para evitar isso implementei justamente a forma mais viável, pegar sempre o
> último código cadastrado e somar + 1, se na hora de gravar alguém fez isso
> miléssimos de segundos antes, então haverá um erro retornável, o sistema
> interceptará e realizará nova tentativa + 2 e assim até conseguir gravar.
>
> Até hoje não encontrei outra solução mais viável que essa para evitar
> buracos na numeração.
>
> Luis
>
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br]
> Em
> nome de Sandro Souza
> Enviada em: quinta-feira, 3 de dezembro de 2009 02:15
> Para: FireBase; Josauro S. J.
> Assunto: Re: [firebase-br] Otimização de Transação
>
> Bom dia/tarde Josauro.
>
> No meu caso, faço tudo dentro de uma única transação, mas como você
> mesmo citou, o problema de dois ou mais usuários tentarem utilizar o
> mesmo código devido à concorrência existe realmente. A única vantagem,
> no meu caso, é não necessitar de uma tabela de códigos reaproveitáveis,
> mas no restante, não foge dos problemas que você já está passando.
>
> Como já foi citado várias vezes em outros posts, o uso de
> geradores/sequences poderia realmente resolver essa questão de
> concorrência, mas por outro lado, fugiria a reutilização de códigos como
> é o nosso caso.
>
> Uma outra abordagem poderia ser a seguinte:
>
> 1 - Todas as chaves estrangeiras seriam criadas utilizando a opção "ON
> UPDATE CASCADE".
>
> 2 - Utilizaríamos geradores/sequences, e dessa forma, nas inclusões não
> reutilizaríamos mais os códigos excluídos, ganhando performance e nos
> livrando de problemas de concorrência no que se refere ao uso do mesmo
> código.
>
> 3 - Criaríamos uma stored procedure que seria acionada sempre que
> desejássemos encontrar essas "brechas" de código em cada uma das tabelas
> dos nossos bancos, e encontrando-as, executaria UPDATEs nesses campos
> chaves para efetuar as "correções" e rearrumar os códigos para deixar
> tudo sequencial e sem essas "brechas". Como as chaves estrangeiras
> teriam sido criadas com a opção "ON UPDATE CASCADE" (item 1), esses
> mesmos códigos nas tabelas filhas/detalhes seriam automaticamente
> alinhados/ajustados pelo próprio banco. Para caad tabela que sofreu
> ajustes de código, seu respectivo gerador/sequence também seria reajustado.
>
> Dessa forma, eu acredito que teriamos uma forma melhor de conseguir o
> que pretendemos.
>
> Sei que o fato de deixar essas "brechas" de código não tem realmente
> qualquer impacto negativo no sistema, que viveria tranquilamente com
> isso, e que essa necessidade de manter todos os códigos em ordem
> sequencial e sem "brechas" é apenas questão de gosto pessoal,
> "perfumaria" ou simplesmente ter a sensação de que tudo está organizado
> no banco, e que só haveria necessidade real disso se por acaso
> tivéssemos tabelas com tantos registros que poderia acontecer de esgotar
> os valores disponíveis para os campos chaves.
>
> No meu caso específico, assumo que se trata apenas de gosto pessoal mesmo.
>
> Josauro, o que você acha dessa nova abordagem?
>
> Espero ter ajudado mais que atrapalhado. :D
>
> Josauro S.J. escreveu:
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>