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

Luis luisfirevb em gmail.com
Seg Dez 7 08:24:42 -03 2009


Sandro isso seria muito mais fácil e ocuparia menos espaço em disco se
fizesse assim:

Criar uma nova tabela só para ocorrências

0 - ID (autonumeração)
1 - IDTabelaTransacao
2 - Nome da Tabela transacionada
3 - Código do usuário que transacionou um registro
4 - Data e hora da transação
5 - Tipo de transação (0=Inclusão, 1=consulta, 2=alteração, 3=exclusão
4=Inativação)
6 - Descrição (se quiser pode criar um campo para saber as modificações
feitas).

Com isso você teria tudo numa única tabela e sem campos em branco no mesmo
registro, pois quem inclui não altera e não exclui e vice-versa. Pode ainda
incluir outras informações como IP da máquina, etc... O bom disso é que você
sabe quantas pessoas alteraram o mesmo registro e não somente o último, além
de não ficar com campos inúteis em registros que não precisam disso. Essa
tabela pode ser implementada para uma ou várias tabelas que julgar
necessário, deixando as sem importância de lado, ou quando achar necessário,
basta mudar o código de gravar do aplicativo para acrescentá-las sem alterar
em nada a estrutura do banco.

Luis


-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Sandro Souza
Enviada em: domingo, 6 de dezembro de 2009 07:52
Para: renato.smiranda em gmail.com; FireBase
Assunto: Re: [firebase-br] Otimização de Transação

Bom dia/tarde Renato.

Grande Renato, sim, fica bem melhor, tanto que eu já alterei o sistema 
em PHP aqui para efetuar sempre exclusões "lógicas".

Em 99% das tabelas do sistema, eu acrescentei 6 campos:

1 - Código do usuário que incluiu o registro.
2 - Data e hora da inclusão.
3 - Código do usuário que alterou o registro por último.
4 - Data e hora da última alteração.
5 - Código do usuário que excluiu o registro.
6 - Data e hora da exclusão.

Nesse caso, os 4 primeiros campos são obrigatórios, mas os 2 últimos são 
apenas preenchidos quando o usuário exclui o registro pelas páginas em 
PHP, e nessa nova situação, o registro fica "logicamente excluido", 
lembrando os jurássicos arquivos DBFs do Clipper/dBase, que também tem 
um byte por registro que funciona como flag de exclusão.

Até para saber quem excluiu o quê fica fácil, além de também ser fácil 
"ressucitar" os registros excluídos.

Como fiz uma classe de "motor de cadastro", ficou fácil, pois 
acrescentei essa funcionalidade na classe, e automaticamente todos os 
cadastros (instâncias dessa mesma classe) já ganharam esse recurso.

De qualquer forma, a rotina para o caso anterior já está pronta, e como 
não haverá mais "buracos de código" nessa nova filosofia, minha classe 
não perderá mais tempo tentando encontrar as brechas, pois quando 
comparar o "MAX(CampoChave)" com o "Count(*)", saberá que não há 
brechas, e já calcula o próximo valor a ser utilizado imediatamente.

Agradeço imensamente pela dica, e foi ótimo ver que os pensamentos 
acabam convergindo para a mesma solução prática. :D

Valeu Renato. :D

Renato Miranda escreveu:
> Sandro, tudo bem ?
>
> Não seria mais simples, para evitar "buracos" na seqüência, em vez de
> excluir o registro, apenas marcá-lo como inativo ?
>
>   

______________________________________________
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





Mais detalhes sobre a lista de discussão lista