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

[Luis]

Quem disse que é "Auditoria de Sistema = informática"?
Leia melhor antes de responder colega, disse ..." Trabalho com auditoria de
normas técnicas" isso é PBQP-H, ISSO-9001, PROBARE entre outras e não tem
relação direta com informática, mas sim com você excluir um registro de
controle exigido pela norma, por isso a numeração sempre deve ser sequencial
ok?

Antes de responder e criticar como "Berçário", entenda o que leu é mais
profissional.

Luis


-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de RM
Enviada em: quinta-feira, 3 de dezembro de 2009 11:44
Para: FireBase
Assunto: Re: [firebase-br] RES: Otimização de Transação

Auditoria e Controle...

Isso só existe se no mínimo todas as alterações/modificações do banco sejam 
registradas por mecanismo de LOG (Isso sim seria auditoria do DB)...

Menos que isso é coisa de berçário...


t++

--------------------------------------------------
From: "Luis" <luisfirevb em gmail.com>
Sent: Thursday, December 03, 2009 9:24 AM
To: "'FireBase'" <lista em firebase.com.br>
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
> 

______________________________________________
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