POSTGRESQL TRIGGER COM PARAMETRO
Olá
Estou precisando fazer uma trigger no postgresql só que com parâmetro. Preciso informar o usuário que esta logado no sistema e não o usuário do banco de dados.
Essa trigger é para auditoria no sistema.
Alguém sabe? Ou tem outra ideia?
Estou precisando fazer uma trigger no postgresql só que com parâmetro. Preciso informar o usuário que esta logado no sistema e não o usuário do banco de dados.
Essa trigger é para auditoria no sistema.
Alguém sabe? Ou tem outra ideia?
Caro ALEXPASSOS
auditoria em sistemas com dependencias de TRIGGER talves não seria uma boa proatica pois qq usuario no do sistema pode desabilitar triggers em banco de dados.
O PostgreSQL disponibiliza duas variáveis importantes para serem usadas em conjunto com as triggers-por-linha: NEW e OLD.
A variável NEW, no caso do INSERT, armazena o registro que está sendo inserido. No caso do UPDATE, armazena a nova versão do registro depois da atualização.
A variável OLD, no caso do DELETE, armazena o registro que está sendo excluÃdo. No caso do UPDATE, armazena a antiga versão do registro depois da atualização.
Isso fica com o gargalo de cada tabela possuir uma ou mais TRIGGER para processo de informação ou conjunto de informações.
O correto seria utilizar serviços de jobs, um pouco mais complexo e mais eficaz isso ficaria independente para seus usuários de acesso e teria dominio amplo não só para tabelas mas para todos os objetos de seu banco de dados.
Boa sorte
auditoria em sistemas com dependencias de TRIGGER talves não seria uma boa proatica pois qq usuario no do sistema pode desabilitar triggers em banco de dados.
O PostgreSQL disponibiliza duas variáveis importantes para serem usadas em conjunto com as triggers-por-linha: NEW e OLD.
A variável NEW, no caso do INSERT, armazena o registro que está sendo inserido. No caso do UPDATE, armazena a nova versão do registro depois da atualização.
A variável OLD, no caso do DELETE, armazena o registro que está sendo excluÃdo. No caso do UPDATE, armazena a antiga versão do registro depois da atualização.
Isso fica com o gargalo de cada tabela possuir uma ou mais TRIGGER para processo de informação ou conjunto de informações.
O correto seria utilizar serviços de jobs, um pouco mais complexo e mais eficaz isso ficaria independente para seus usuários de acesso e teria dominio amplo não só para tabelas mas para todos os objetos de seu banco de dados.
Boa sorte
Então qual é real finalidade da trigger? Não entendi, pensei que fosse uma alternativa para auditoria que o próprio banco fazia.
Caro ALEXPASSOS
Si mé para auxiliar no processo porem tem sua ação facilmente manipulada por qq usuário no sistema.
Sotored Procedure, Function, View Sequence, entre outro tem uma segurança em sua construção e podem ser criptografadas e sua manipulação bloqueda e restringida já a trigger pode facilmente ser anulada por qualquer usuario no banco
Basta esse comando para manipular sua ação [Ô]DISABLE TRIGGER all[Ô] e Habiliatar só trocar [Ô]ENABLE TRIGGER all[Ô]
O funcionamento da trigger é para tratar os eventos de INSERT, UPDATE e DELETE que ocorre na tabela para geração de informação, auditorias e históricos, porem para alguns usuário que querem burlar este processo basta desabilitar de forma genérica que elas param de funcionar
Para as TRIGGERS funcionar de fato basta não fornecer as senhas de acesso ao Banco de dados de qualquer nÃvel de usauário.........
Boa Sorte
Citação::
Então qual é real finalidade da trigger? Não entendi, pensei que fosse uma alternativa para auditoria que o próprio banco fazia.
Si mé para auxiliar no processo porem tem sua ação facilmente manipulada por qq usuário no sistema.
Sotored Procedure, Function, View Sequence, entre outro tem uma segurança em sua construção e podem ser criptografadas e sua manipulação bloqueda e restringida já a trigger pode facilmente ser anulada por qualquer usuario no banco
Basta esse comando para manipular sua ação [Ô]DISABLE TRIGGER all[Ô] e Habiliatar só trocar [Ô]ENABLE TRIGGER all[Ô]
O funcionamento da trigger é para tratar os eventos de INSERT, UPDATE e DELETE que ocorre na tabela para geração de informação, auditorias e históricos, porem para alguns usuário que querem burlar este processo basta desabilitar de forma genérica que elas param de funcionar
Para as TRIGGERS funcionar de fato basta não fornecer as senhas de acesso ao Banco de dados de qualquer nÃvel de usauário.........
Boa Sorte
Ok.. mais se eu não fornecer a senha de acesso ao banco não vou ter problemas com isso.
Outra dúvida:
1 - Estava lendo que a trigger pode deixar o banco e o sistema mais lento?
2 - Caso o usuário desabilite as triggers, tem como meu sistema verificar e habilitar?
Outra dúvida:
1 - Estava lendo que a trigger pode deixar o banco e o sistema mais lento?
2 - Caso o usuário desabilite as triggers, tem como meu sistema verificar e habilitar?
Caro ALEXPASSOS
Fornecer ou não fornecer a senha de acesso ao Banco é uma questão de contrato ficar responsável pelo banco ou não.......
Trigger mal construida pode sim realmente pois se descadear loop infinito acarreta em consumo de memória e por sua vez travar alguns processos pois agem no evento de cada tabela, ter que ter muita cautela quando fazer triggers para geração de inventários nos dados e ações de manutenção nos dados.
é possÃvel fazer um select e verificar todas as triggers existentes no banco e saber se estão habilitadas e desabilitadas mas vai ficar honeroso para o banco quando essa procedure ou function ser executada, vai depender das regras para o evento............
PODE SER FEITA UM ASELECT UTILIZANDO AS RTEGRAS DA sysobjects
Exemplo básico de consulta das triggers existentes no banco
=================================================================================================
Select (Select name from sysobjects x where x.id=tr.parent_obj) Tabela, Name as NomeTrigger,
ObjectProperty(Object_id(Name),[ô]ExecIsTriggerDisabled[ô]) Habilitado
From sysobjects trWhere xtype = [ô]tr[ô] and name not like [ô]log%[ô]
Order by Tabela, Name
===================================================================================================
Boa sorte
Fornecer ou não fornecer a senha de acesso ao Banco é uma questão de contrato ficar responsável pelo banco ou não.......
Trigger mal construida pode sim realmente pois se descadear loop infinito acarreta em consumo de memória e por sua vez travar alguns processos pois agem no evento de cada tabela, ter que ter muita cautela quando fazer triggers para geração de inventários nos dados e ações de manutenção nos dados.
é possÃvel fazer um select e verificar todas as triggers existentes no banco e saber se estão habilitadas e desabilitadas mas vai ficar honeroso para o banco quando essa procedure ou function ser executada, vai depender das regras para o evento............
PODE SER FEITA UM ASELECT UTILIZANDO AS RTEGRAS DA sysobjects
Exemplo básico de consulta das triggers existentes no banco
=================================================================================================
Select (Select name from sysobjects x where x.id=tr.parent_obj) Tabela, Name as NomeTrigger,
ObjectProperty(Object_id(Name),[ô]ExecIsTriggerDisabled[ô]) Habilitado
From sysobjects trWhere xtype = [ô]tr[ô] and name not like [ô]log%[ô]
Order by Tabela, Name
===================================================================================================
Boa sorte
é ... estou vendo que é melhor fazer essa auditoria na mão mesmo.
Caro ALEXPASSOS
Mesmo com a possibilidade simples de disabiliatar as triggers ainda é a opção mais prática de fazer auditoria, pois existem outras formas como por exemplo:
elaborar sua stored procedures para fazer tratamento nas ações de INSERT UPDATE e DELETE mas fica complexo porem seguro de qualquer ação de outros usuários,
Function criptografacas tambem é uma boa forma de tratar as ações
é tudo uma questão de conjunto de processos e se teu ambeinte é crÃtico ou não.
Tenho alguns problemas por causa de hierarquia de usuário ficar mechendo no banco e o que fiz foi montar um JOB para realizar todas as auditorias necessárias, funcionou perfeitamente e peguei ainda todas as ocorrências de ERROS, MALANDRAGEM, TUDO QUE OCORRIA DE ANORMAL NA INCLUSÂO, ALTERAÇÃO e EXCLUSÃO DE DADOS...........
O Problema é que porconta da autorização de acesso a usuários no banco tive que fazer um processo separado dentro do banco para garantir e levantar todo o histórico de manipulação de dados, ficou grande e complexo funciona perfeitamente, não é lento, extremamente eficaz porem levou 4 vezes mais tempo que se tivesse feito por triggers.
Se em sua base de dados todos os usuário que tem acesso não for CURIOSO e BISBILHOTEIRO a melhro solução é TRIGGER senão tem que partir para o plano B ou C.
Boa Sorte
Mesmo com a possibilidade simples de disabiliatar as triggers ainda é a opção mais prática de fazer auditoria, pois existem outras formas como por exemplo:
elaborar sua stored procedures para fazer tratamento nas ações de INSERT UPDATE e DELETE mas fica complexo porem seguro de qualquer ação de outros usuários,
Function criptografacas tambem é uma boa forma de tratar as ações
é tudo uma questão de conjunto de processos e se teu ambeinte é crÃtico ou não.
Tenho alguns problemas por causa de hierarquia de usuário ficar mechendo no banco e o que fiz foi montar um JOB para realizar todas as auditorias necessárias, funcionou perfeitamente e peguei ainda todas as ocorrências de ERROS, MALANDRAGEM, TUDO QUE OCORRIA DE ANORMAL NA INCLUSÂO, ALTERAÇÃO e EXCLUSÃO DE DADOS...........
O Problema é que porconta da autorização de acesso a usuários no banco tive que fazer um processo separado dentro do banco para garantir e levantar todo o histórico de manipulação de dados, ficou grande e complexo funciona perfeitamente, não é lento, extremamente eficaz porem levou 4 vezes mais tempo que se tivesse feito por triggers.
Se em sua base de dados todos os usuário que tem acesso não for CURIOSO e BISBILHOTEIRO a melhro solução é TRIGGER senão tem que partir para o plano B ou C.
Boa Sorte
Tópico encerrado , respostas não são mais permitidas