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

[Kleber Caneva]

Isso parece muito com o controle de numeração de NF. Nesse caso acho que 
você pode fazer de outra forma.

1) Use um Generator para a PK. Esse não interessa se será ou não sequencial. 
Ele é usado apenas para garantir que não haverá PK repetida..

2) Você irá criar um outro campo de controla para o nº do seu documento 
(Protocolo). Esse campo será sequencial e sem pulos. Para isso crie uma TG e 
dentro dela vc alimenta esse campo com um segundo Generator.

Ele só irá incrementar se realmente for gravado.
Com isso caso ocorra cancelamento no meio do caminho, a PK ficará pulada. 
Mas o nº do documento

Não podemos confundir a função de uma PK, com um campo sequencial que o 
cliente precisa. Por comodidade nossa, é comum utilizarmos a PK com codigo 
para o cliente.

[]´s

Kléber Caneva

----- Original Message ----- 
From: "Luis" <luisfirevb em gmail.com>
To: "'FireBase'" <lista em firebase.com.br>
Sent: Thursday, December 03, 2009 9:24 AM
Subject: [firebase-br] RES: Otimização de Transação


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

E-mail verificado pelo Terra Anti-Spam.
Para classificar esta mensagem como spam ou não spam, visite
http://ecp.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCY0NDU0NzM0I3Blcm0hdGVycmEmMSwxMjU5ODM5NzI1LjU4MjkwMi41OTI4LjE1YS50cG4udGVycmEuY29tLDg5NzI=TerraMail
Verifique periodicamente a pasta Spam para garantir que apenas mensagens
indesejadas sejam classificadas como Spam.