[1/2 Off] Tabelas de log para sistema web em PHP

[Eduardo Alexandre]

Olá,

Estou com necessidade de implementar um sistema que disponha de recursos de log de todas as ações realizadas no sistema, sendo que para cada uma das ações de inserir, listar, alterar ou remover dados, devem ser logados:

- Login e logoff (ip, usuário);

- Select, Insert ou delete de dados (ip, usuário, tabela, campo, valor)

- Update de dados (ip, usuário, tabela, campo, valor anterior, valor novo)

Alguém implementou similar?

Estou pensando no aumento do tamanho dessa tabela, principalmente quanto aos selects e updates. Sugerem dividir em tabelas por tipo de ação de log?

Abraços,

Eduardo

[Michel Felipe]

Boa tarde Eduardo,


Analisando sua necessidade (e de situações encontradas em sistemas em que efetuei manutenção), tenho as seguintes sugestões:

1 - Qual o banco q vc esta usando? Caso seja Postgres vc pode criar um schema dentro do seu banco específico para logs. No entanto, ainda assim o seu banco irá crescer bastante e vc terá problemas com backups e administração em geral. Então, vc pode criar um outro banco específico para logs. Ainda q ele seja grande, ao menos vc teria um tamanho específico para log e outro diferente para aplicação.

2 - Vc pode criar uma abordagem de logs em arquivos (.txt, .ini ou até mesmo .yml). A desvantagem disso é q vc n teria a vantagem de um banco de dados relacional e nem utilizaria SQL. Basicamente, vc teria q trabalhar isso na forma de salvar no arquivo e para leitura, na linguagem de programação que vc utiliza. Geralmente, utiliza-se array's e strings para leitura e escrita nesses tipos de arquivos. Existem algumas classes na net que auxiliam nesse trabalho (sobretudo, para arquivos yml e .ini). Eu possuo uma lib para arquivos .ini muito parecida com a classe Properties do Java.
      A vantagem é q dessa forma vc n se preocuparia tanto com o tamanho e poderia trabalhar com compactação(.rar, gzip, .tar e etc...) e obviamente, utilizar técnicas de backup de tempos em tempos desses arquivos.

3 - Utilizar um banco SQLITE para salvar os logs...teria a vantagem de utilzar SQL e este banco é basicamente um arquivo!. Tanto q na conexão dele vc aponta onde o seu arquivo se encontra. N sei até q ponto os arquivos do SQLITE podem ser compactados e se o nivel de compactação dele é bom (so testando)

Sobre dividir as ações...é interessante, ter uma tabelão com váááriossss registros pode ser um problema em algumas situações (isso tbm serve para logs em arquivos).

Bom...fica as dicas. Por favor, leia com calma e nos dê um feedback sobre o q vc achou e qual a escolhida

--
Você está recebendo esta mensagem porque se inscreveu no grupo "php-brasil" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para php-b...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para php-brasil+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/php-brasil?hl=pt-BR.

--
Atenciosamente



Analista de Sistemas Jr
71 8767-6515
www.vidacriativa.com.br

[Eduardo Alexandre]

Olá Michel,

Sim, o banco a princípio é em PostgreSQL.

A possibilidade do uso de arquivos não seria viável devido a necessidade obrigatória de se utilizar um banco de dados SQL transacional.

Quanto ao SQLite, pra ser sincero, não conheço sua escalabilidade quando os dados aumentam em demasia. Por exemplo, se 100 usuários fizerem pesquisa e exibirem os dados de pessoas, sendo listados 10 campos de 300 pessoas cada, resultaria em 100 vezes 300 x 10. Isso ao longo de 1 ou mais anos me preocuparia.

Fico portanto com a opção de criar um segundo schema ou um outro database, o que me parece mais interessante.

Estou dando uma pensada a respeito do MER. Jájá retorno a versão 0.1. :)

Abraços,

Eduardo

[Eduardo Alexandre]

Olá.

A princípio foi isso que pensei:

Para um sistema normal, a tabela "log" resolve. Porém separei por tipo de ação, sendo:

- 1 tabela para update.

- 2 tabelas para select, permitindo o log de n registros para cada tabela.

- 2 tabelas para insert e delete, permitindo o log de n registros para cada tabela.

O tipo de dados "text" foi escolhido por poder armazenar todos os tipos de dados utilizados no banco de dados.

Sugestões? Críticas? Comentários?

Abraços!

[Falci]

Há alguns dias, eu estava olhando as tabelas do wordpress.
Quando vc edita um post, ele não faz um "update", mas faz um novo insert na tabela.
Assim ele tem todas as versões anteriores. E cada versão tem a data/hora de "edição", assim como o ID do usuário

[Michel Felipe]

Bom...eu n entendi a: "a necessidade obrigatória de se utilizar um banco de dados SQL transacional" sendo q vc utilizaria os arquivos APENAS PARA OS LOGS e n para o sistema como um todo, mas tdobm.

No seu DER vc utilizou Generalização...a nível de estrutura ta legal mas de qualquer forma a tabela "mãe" dos tipos de ações (a tabela log) irá armazenar dados comuns a todos eles. Ou seja, quando vc quiser saber quais os SELECT's do usuário de ID 11 por exemplo, vc irá primeiro acessar a log e fazer um join com a log_select correto? Se sua preocupação é o tamanho isso n irá ajudar muito já q, a log terá dados de todos os tipos de log.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "php-brasil" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para php-b...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para php-brasil+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/php-brasil?hl=pt-BR.

[Eduardo Alexandre]

Bem, isso poderia ser resolvido "duplicando" as informações de id_usuário(integer) e momento_do_log(timestamp) para as tabelas log_insert_delete, log_select e log_updade.

Assim, para saber quais os SELECT's do usuário de ID 11 por exemplo, bastaria acesso a uma tabela apenas e assim por diante com updates, delete e insert.

Bem, por mim, finalizo por aqui e desde já meu muito obrigado!

ps.: a necessidade de ser somente com BD SQL transacional é devido a desejo interno e alguns "detalhes" que são requisitados para uma possível certificação futuramente. São pedidos itens como: "deve ser protegido por um Sistema de Gerenciamento de Banco de Dados" (o SQLite na realidade é um arquivo).

Abraços,
____________________
Eduardo Alexandre

* LDP-BR - Projeto Brasileiro de Documentação e Tradução do Linux. Visite http://br.tldp.org e conheça.
* Use BrOffice.org - Baixe gratuitamente em http://www.broffice.org/download.

* Projeto de lei nº 607 de 2007 - Dispõe sobre a regulamentação dos profissionais de informática e cria o Conselho Federal e os Conselhos Regionais de Informática.

[Dlani]

O MYSQL tem uma engine chamada ARCHIVE que é justamente para tabela de logs.