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

[Luis]

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: