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

Qui Dez 3 13:45:45 -03 2009

Mas acredito que a solução seriam os logs e não permissão de  
exclusão dos registros e sim inativacao dos mesmos.
Abraços

Enviado de meu iPhone

Em 03/12/2009, às 13:20, Luis <luisfirevb em gmail.com> escreveu:

> 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 se 
> quencial
> 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 mi 
>> nha
>> 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 im 
>> plica 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". Exem 
>> plo: 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 v 
>> ocê
>> 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á passan 
>> do.
>>
>> 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õe 
>> s 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 m 
>> esmo
>> 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 t 
>> abelas
>> dos nossos bancos, e encontrando-as, executaria UPDATEs nesses campos
>> chaves para efetuar as "correções" e rearrumar os códigos para dei 
>> xar
>> 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 realme 
>> nte
>> 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á organ 
>> izado
>> no banco, e que só haveria necessidade real disso se por acaso
>> tivéssemos tabelas com tantos registros que poderia acontecer de e 
>> sgotar
>> os valores disponíveis para os campos chaves.
>>
>> No meu caso específico, assumo que se trata apenas de gosto pessoa 
>> l 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
>
>
> ______________________________________________
> 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