Em 11 de maio de 2012 17:34, Flavio Henrique Araque Gurgel <
[email protected]> escreveu:

> Em 11-05-2012 17:29, Bruno Silva escreveu:
> > Entendo, mas Flávio, não sei se minha idéia está sendo muito pontual, é
> > que a meu ver se já sei quem eh o usuario da aplicacao, o que impede eu
> > criar uma coluna para registrar seu nome?
>
> Nada te impede. Já fiz assim em n bancos de dados.
>

não mesmo.


>
> > E a partir daí criar tabelas de logs e com triggers fazer o sistema
> > registrar um 'historico' das modificações em cada tupla e permitir que o
> > usuario do banco ( que o pool usa ) só faça inserts nessa tabela de log?
>
> Perfeito.
>
É assim que coloco auditoria em muitos bancos de dados.
>

Mas como garantir a integridade de acesso aos dados? Grant e afins...
podemos dizer quem acessou aquele dado, mas acho que seria interessante
realmente garantir este tipo de acesso, alteração e etc...


> Sempre que usamos pools (servidores de aplicação Java, pgbouncer, PHP
> com persistent connections, etc) caímos nesse dilema.
>

Bem, se estamos querendo garantir que o usuário logado seja um usuário no
SGBD e ainda utilizar um pool de conexões, acredito que não dê. Ao menos
com o implementação de ORM que costumo utilizar, o "Mega amado pelo Dutra"
Hibernate. Pois o método getConection() neste ORM esta marcado como
depreciado e a documentação diz que ele será reimplementado no futuro.

Então um Set Session ou algo parecido, crio que não funcionaria. Ademais
sim, é só fazer este tipo de vinculação que você e o Xará comentaram, é até
o mais usual, mas também perco as garantias dos grants... acho que discuti
isso uma vez no fim do ano passado, pelos idos de outubro aqui na lista...

é só meu ponto de vista.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a