Ottenere eventi da un database

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

Domanda

Non ho molta familiarità con i database e ciò che offrono al di fuori delle operazioni CRUD.

La mia ricerca mi ha portato a trigger . Fondamentalmente sembra che i trigger offrano questo tipo di funzionalità:

  

(da Wikipedia )

     

Esistono in genere tre eventi di innesco che causano l'attivazione di " fire " ;:

     
      
  • Evento INSERT (mentre un nuovo record viene inserito nel database).
    •   
  • evento UPDATE (poiché un record viene modificato).
    •   
  • ELIMINA evento (durante l'eliminazione di un record).
    •   

La mia domanda è: c'è un modo in cui posso essere avvisato in Java (preferibilmente includendo i dati che sono cambiati) dal database quando un record viene aggiornato / cancellato / inserito usando una sorta di semantica di trigger?

Quali potrebbero essere alcune soluzioni alternative a questo problema? Come posso ascoltare gli eventi del database?

Il motivo principale per cui voglio farlo è uno scenario come questo :

Ho 5 applicazioni client tutte in processi diversi / esistenti su PC diversi. Tutti condividono un database comune (Postgres in questo caso).

Supponiamo che un client modifichi un record nel DB che tutti e 5 i client sono "interessati". sto provando a pensare ai modi in cui i clienti possono essere "notificati" della modifica (preferibilmente con i dati interessati allegati) anziché effettuare una query per i dati a intervalli regolari.

È stato utile?

Soluzione

Utilizzando Oracle è possibile impostare un trigger su una tabella e fare in modo che il trigger invii un messaggio JMS. Oracle ha due diverse implementazioni JMS. È quindi possibile disporre di un processo che "ascolterà" il messaggio utilizzando il driver JDBC. Ho usato questo metodo per inviare le modifiche alla mia applicazione rispetto al polling. Se si utilizza un database Java (H2) sono disponibili opzioni aggiuntive. Nella mia attuale applicazione (SIEM) ho trigger in H2 che pubblicano eventi di modifica usando JMX.

Altri suggerimenti

Non confondere il database (che contiene i dati) e gli eventi su tali dati.

I trigger sono a senso unico, ma normalmente avrai un livello di persistenza nella tua applicazione. Questo livello può scegliere di attivare eventi quando si verificano determinate cose, ad esempio un argomento JMS.

I trigger sono un ultimo problema, dato che stai operando su elementi relazionali, piuttosto che "eventi". sui dati. (Ad esempio, un "aggiornamento", potrebbe in realtà essere mappato a un evento "società con nome legale" modificato) Se si fa affidamento sul db, sarà necessario mappare gli inserti & amp; aggiornamenti agli eventi della vita reale .... di cui già sapevi!

Puoi quindi sovrapporre altre cose sopra queste notifiche - come l'elaborazione del flusso di eventi - per trovare eventi a cui altri sono interessati.

James

Hmm. Quindi stai usando PostgreSQL e vuoi " ascoltare " per eventi ed essere "quotati" quando si verificano?

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

Spero che questo aiuti!

La chiamata di processi esterni dal database è molto specifica per il fornitore.

Appena al di sopra della mia testa:

  • SQLServer può chiamare programmi CLR da trigger,

  • postgresql può chiamare C arbitrario funzioni caricate dinamicamente,

  • MySQL può chiamare funzioni C arbitrarie, ma devono essere compilati in

  • Sybase può effettuare chiamate di sistema se impostato a farlo.

La cosa più semplice da fare è fare in modo che i trigger di inserimento / aggiornamento / eliminazione inseriscano una tabella di registro e che il programma java controlli tale tabella. Le colonne valide da includere nella tabella di registro potrebbero essere EVENT_CODE, LOG_DATETIME e LOG_MSG.

A meno che tu non abbia bisogno di prestazioni molto elevate o di dover gestire 100K di record, questo è probabilmente sufficiente.

Penso che tu confonda due cose. Entrambi sono altamente specifici per i fornitori di database.

Il primo che chiamerò "innesca". Sono sicuro che c'è almeno un fornitore di DB che pensa che i trigger siano diversi da questo, ma abbiate pazienza. Un trigger è un pezzo di codice sul lato server che può essere collegato alla tabella. Ad esempio, è possibile eseguire una procedura memorizzata PSQL su ogni aggiornamento nella tabella X. Alcuni database consentono di scriverli in veri e propri linguaggi di programmazione, altri solo nella loro variante di SQL. I trigger sono in genere ragionevolmente veloci e scalabili.

L'altro che chiamerò "eventi". Si tratta di trigger attivati ??nel database che consentono di definire un gestore eventi nel programma client. Ad esempio, ogni volta che ci sono aggiornamenti al database dei client, attiva updateClientsList nel tuo programma. Ad esempio, usando python e firebird vedi http://www.firebirdsql.org/devel/python/docs/3.3.0/beyond-python-db-api.html#database-event-notification

Credo che il suggerimento precedente di usare un monitor sia un modo equivalente per implementarlo usando qualche altro database. Forse oracolo? Anche i servizi di notifica MSSQL, menzionati in un'altra risposta, sono un'altra implementazione di questo.

Vorrei dire che faresti meglio a VERAMENTE sapere perché vuoi che il database avvisi il tuo programma client, altrimenti dovresti rimanere con i trigger sul lato server.

Ciò che stai chiedendo dipende completamente sia dal database che stai utilizzando sia dal framework che stai utilizzando per comunicare con il tuo database.

Se stai usando qualcosa come Hibernate come livello di persistenza, ha una serie di ascoltatori e intercettori che puoi usare per monitorare i record che entrano ed escono dal database.

Ci sono alcune tecniche diverse qui a seconda del database che stai usando. Un'idea è quella di eseguire il polling del database (che sono sicuro che stai cercando di evitare). Fondamentalmente potresti controllare le modifiche ogni tanto.

Un'altra soluzione (se si utilizza SQL Server 2005) è utilizzare Notification Services, sebbene questa tecnologia sia presumibilmente sostituita in SQL 2008 (non ne abbiamo ancora visto un sostituto, ma Microsoft ne ha parlato pubblicamente) .

Se stai usando Oracle, dai un'occhiata a questo post precedente .

Di solito è a questo che serve l'applicazione client / server standard. Se tutti gli inserimenti / aggiornamenti / eliminazioni passano attraverso l'applicazione server, che quindi modifica il database, le applicazioni client possono scoprire molto più facilmente quali modifiche sono state apportate.

Se stai usando postgresql ha la capacità di ascoltare notifiche dal client JDBC .

Suggerirei di utilizzare una colonna data / ora, ultimo aggiornamento, insieme possibilmente all'utente che aggiorna il record, e quindi consentire ai client di controllare la data / ora del record locale rispetto a quella del record persistente.

La complessità aggiunta dell'aggiunta di una funzionalità di richiamata / trigger non è valsa la pena secondo me, a meno che non sia supportata dal back-end del database e dalla libreria client utilizzata, come ad esempio i servizi di notifica offerti per SQL Server 2005 utilizzati insieme ad ADO. NET.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top