Obtendo eventos a partir de um banco de dados

StackOverflow https://stackoverflow.com/questions/812233

Pergunta

Eu não estou muito familiarizado com bancos de dados eo que eles oferecem fora das operações CRUD.

A minha pesquisa me levou a gatilhos . Basicamente parece que gatilhos oferecer esse tipo de funcionalidade:

(de Wikipedia )

Há tipicamente três eventos desencadeantes que causam gatilhos para "fogo":

  • evento de inserção (como um novo registro está sendo inserido no banco de dados).
  • evento UPDATE (como um registro está sendo alterado).
  • Excluir evento (como um registro está sendo excluído).

A minha pergunta é: existe alguma maneira eu posso ser notificado em Java (de preferência incluindo os dados que mudaram) pelo banco de dados quando um registro é atualizado / deletadas / insweridas usando algum tipo de semântica gatilho?

O que pode haver algumas soluções alternativas para este problema? Como posso ouvir eventos de banco de dados?

A principal razão que eu quero fazer isso é um cenário como este :

Eu tenho 5 aplicativos cliente todos em diferentes processos / existentes em diferentes PCs. Todos eles compartilham um banco de dados comum (Postgres, neste caso).

Vamos dizer que um cliente muda um registro no DB que todos os 5 dos clientes são "interessados". Eu estou tentando pensar em maneiras para os clientes a ser "notificado" da mudança (de preferência com os dados afetados ligados ) em vez de lhes consultando os dados em algum intervalo.

Foi útil?

Solução

Usando o Oracle você pode configurar um gatilho em uma tabela e, em seguida, tem o gatilho enviar uma mensagem JMS. Oracle tem dois JMS implementações diferentes. Você pode então ter um processo que irá 'ouvir' para a mensagem usando o driver JDBC. Eu tenho usado este método para empurrar muda para a minha aplicação vs. polling. Se você estiver usando um banco de dados Java (H2) você tem opções adicionais. Na minha aplicação atual (SIEM) Eu tenho gatilhos em H2 que publicam eventos de alteração usando JMX.

Outras dicas

Não misture o banco de dados (que contém os dados), e eventos do que os dados.

Triggers são uma forma, mas normalmente você vai ter uma camada de persistência na sua aplicação. Esta camada pode optar por disparar eventos quando certas coisas acontecem -. Digamos a um tópico JMS

Triggers são uma última coisa vala, como você está operando em itens relacionais, em seguida, em vez de "eventos" sobre os dados. (Por exemplo, um "update", poderia no mapa a realidade para um "nome legal da empresa mudou" evento) Se você confiar no db, você terá que mapear as inserções e atualizações de volta para eventos da vida real .... que você já sabia sobre!

Você pode então camada outras coisas em cima dessas notificações - como processamento de fluxo de eventos -. Para encontrar eventos que outros estão interessados ??em

James

Hmm. Então você está usando PostgreSQL e você quer que "escute" para eventos e ser "notificado" quando elas ocorrem?

http://www.postgresql.org/docs/8.3/ static / sql-listen.html http://www.postgresql.org/docs/8.3/static/sql -notify.html

Espero que isso ajude!

Chamando processos externos do banco de dados é específico muito fornecedor.

Apenas fora do topo da minha cabeça:

  • SQLServer pode chamar programas CLR de gatilhos,

  • O PostgreSQL pode chamar C arbitrária funções carregadas dinamicamente,

  • MySQL pode chamar funções C arbitrárias, mas eles devem ser coligidos,

  • Sybase pode fazer chamadas de sistema se SET -se a fazê-lo.

A coisa mais simples a fazer é ter a atualização / triggers inserção / exclusão fazer uma entrada em alguma tabela de log, e ter o seu monitor programa java que a tabela. Boas colunas de ter em sua tabela de log seria coisas como EVENT_CODE, LOG_DATETIME e LOG_MSG.

A menos que você precisar de muito alto desempenho ou necessidade de lidar com 100Ks de registros, que é provavelmente suficiente.

Eu acho que você está confundindo duas coisas. Ambos são altamente db específico do fornecedor.

O primeiro que chamarei "gatilhos". Estou certo de que há pelo menos um fornecedor DB que pensa gatilhos são diferentes do que isso, mas urso comigo. Um disparador é uma peça do lado do servidor de código que pode ser ligado à mesa. Por exemplo, você poderia executar um PSQL procedimento armazenado em cada atualização na tabela X. Alguns bancos de dados permitem que você escreva-as em linguagens de programação reais, outros apenas na sua variante do SQL. Triggers são tipicamente razoavelmente rápido e escalável.

O outro chamarei "eventos". Estes são os gatilhos que o fogo na base de dados que permitem definir um manipulador de eventos em seu programa cliente. IE, a qualquer hora há atualizações para o banco de dados de clientes, updateClientsList fogo em seu programa. Por exemplo, usando python e ver firebird http://www.firebirdsql.org/devel/python/docs/3.3.0/beyond-python-db-api.html#database-event-notification

Eu acredito que a sugestão anterior para usar um monitor é uma maneira equivalente a implementar isso usando algum outro banco de dados. Talvez oráculo? serviços de notificação MSSQL, mencionado em outra resposta é outra implementação deste bem.

Eu iria mais longe ao dizer que seria melhor realmente saber por que você deseja que o banco de dados para notificar o seu programa cliente, caso contrário, você deve ficar com gatilhos lado do servidor.

O que você está pedindo completamente depende tanto o banco de dados você está usando e do quadro que você está usando para se comunicar com seu banco de dados.

Se você estiver usando algo parecido com Hibernate como sua camada de persistência, tem um conjunto de ouvintes e interceptores que você pode usar para monitorar registros entrando e saindo do banco de dados.

Existem algumas técnicas diferentes aqui, dependendo do banco de dados que você está usando. Uma idéia é consultar o banco de dados (o que eu tenho certeza que você está tentando evitar). Basicamente, você pode verificar se há alterações a cada tantas vezes.

Outra solução (se você estiver usando SQL Server 2005) é usar os serviços de notificação, embora este Techonology é supostamente sendo substituído no SQL 2008 (ainda não vimos uma substituição pura ainda, mas a Microsoft tem falado sobre isso publicamente) .

Se você estiver usando Oracle, confira este post anterior .

Este é geralmente o que a aplicação cliente / servidor padrão é para. Se todas as inserções / atualizações / exclusões passar pela aplicação de servidor, que, em seguida, modifica o banco de dados, aplicações cliente pode descobrir muito mais fácil que as mudanças foram feitas.

Se você estiver usando PostgreSQL tem capacidade para ouvir notificações do cliente JDBC .

Gostaria de sugerir o uso de uma coluna timestamp, última actualização, juntamente com possivelmente o usuário atualizar o registro, e depois deixar que os clientes verificar o seu timestamp registro local contra a do registro persistente.

A complexidade adicional de adicionar uma funcionalidade callback / gatilho não é apenas vale a pena na minha opinião, a não ser suportado pela infra-estrutura de banco de dados e a biblioteca cliente usado, como por exemplo, os serviços de notificação oferecidos para SQL Server 2005 usado em conjunto com o ADO. NET.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top