Obtención de eventos de una base de datos

Question

No estoy muy familiarizado con las bases de datos y lo que ofrecen fuera de las operaciones de CRUD.

Mi investigación me ha llevado a desencadenantes . Básicamente, parece que los activadores ofrecen este tipo de funcionalidad:

  

(de Wikipedia )

     

Normalmente, hay tres eventos desencadenantes que hacen que los disparadores " dispare " ;:

     

  
• evento INSERT (a medida que se inserta un nuevo registro en la base de datos).
  
• Evento UPDATE (a medida que se modifica un registro).
  
• Evento DELETE (a medida que se borra un registro).
  

Mi pregunta es: ¿hay alguna forma en que la base de datos pueda notificarme en Java (preferiblemente incluyendo los datos que cambiaron) cuando un registro se actualiza / elimina / inserta usando algún tipo de semántica de activación?

¿Cuáles podrían ser algunas soluciones alternativas a este problema? ¿Cómo puedo escuchar los eventos de la base de datos?

La razón principal por la que quiero hacer esto es un escenario como este :

Tengo 5 aplicaciones cliente en diferentes procesos / existentes en diferentes PC. Todos ellos comparten una base de datos común (Postgres en este caso).

Digamos que un cliente cambia un registro en la base de datos de que los 5 clientes están " interesados ??" in. Estoy tratando de pensar en formas para que los clientes sean notificados " " del cambio (preferiblemente con los datos afectados adjuntos) en lugar de que consulten los datos en algún intervalo.

Answer 1

Usando Oracle puede configurar un Disparador en una tabla y luego hacer que el disparador envíe un mensaje JMS. Oracle tiene dos implementaciones JMS diferentes. Luego puede tener un proceso que "escuchará" el mensaje usando el controlador JDBC. He utilizado este método para empujar los cambios a mi aplicación en comparación con el sondeo. Si está utilizando una base de datos Java (H2), tiene opciones adicionales. En mi aplicación actual (SIEM) tengo activadores en H2 que publican eventos de cambio utilizando JMX.

Answer 2

No mezcle la base de datos (que contiene los datos) y los eventos en esos datos.

Los disparadores son de una manera, pero normalmente tendrá una capa de persistencia en su aplicación. Esta capa puede elegir disparar eventos cuando suceden ciertas cosas, por ejemplo, a un tema JMS.

Los disparadores son una última cosa de zanja, ya que estás operando en elementos relacionales en lugar de " eventos " en los datos. (Por ejemplo, una " actualización " ;, en realidad podría asignarse a un " nombre legal cambiado por la empresa " evento) Si confía en la base de datos, tendrá que asignar las inserciones & amp; actualiza de nuevo a los eventos de la vida real ... ¡de los que ya sabías!

Luego puedes colocar otras cosas en la parte superior de estas notificaciones, como el procesamiento del flujo de eventos, para encontrar eventos en los que otros estén interesados.

James

Answer 3

Hmm. Entonces, estás usando PostgreSQL y quieres " escuchar " para eventos y ser " notificado " cuando ocurren?

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

Espero que esto ayude!

Answer 4

Llamar a procesos externos desde la base de datos es muy específico del proveedor.

Justo en la parte superior de mi cabeza:

• SQLServer puede llamar a programas CLR desde desencadenantes,

• postgresql puede llamar C arbitraria funciones cargadas dinámicamente,

• MySQL puede llamar funciones C arbitrarias, pero deben ser compilados en,

• Sybase puede hacer llamadas al sistema si está configurado para hacerlo.

Answer 5

Lo más sencillo es hacer que los activadores de inserción / actualización / eliminación hagan una entrada en alguna tabla de registro y que su programa Java controle esa tabla. Buenas columnas para tener en tu tabla de registro serían cosas como EVENT_CODE, LOG_DATETIME y LOG_MSG.

A menos que necesite un rendimiento muy alto o necesite manejar 100Ks de registros, probablemente sea suficiente.

Answer 6

Creo que estás confundiendo dos cosas. Ambos son muy específicos del proveedor de db.

El primero al que llamaré " disparadores " ;. Estoy seguro de que hay al menos un proveedor de DB que cree que los desencadenantes son diferentes a esto, pero tengan paciencia conmigo. Un disparador es una parte del código del lado del servidor que se puede adjuntar a la tabla. Por ejemplo, podría ejecutar un procedimiento almacenado de PSQL en cada actualización de la tabla X. Algunas bases de datos le permiten escribirlas en lenguajes de programación reales, otras solo en su variante de SQL. Los disparadores suelen ser razonablemente rápidos y escalables.

El otro lo llamaré "eventos". Estos son activadores que se activan en la base de datos que le permiten definir un controlador de eventos en su programa cliente. IE, siempre que haya actualizaciones de la base de datos de clientes, active updateClientsList en su programa. Por ejemplo, utilizando python y firebird, vea http://www.firebirdsql.org/devel/python/docs/3.3.0/beyond-python-db-api.html#database-event-notification

Creo que la sugerencia anterior de usar un monitor es una forma equivalente de implementar esto usando alguna otra base de datos. Tal vez oracle? Los servicios de notificación de MSSQL, mencionados en otra respuesta, son otra implementación de esto también.

Iría tan lejos como para decir que es mejor que REALMENTE sepa por qué quiere que la base de datos notifique al programa de su cliente, de lo contrario, debería atenerse a los activadores del lado del servidor.

Answer 7

Lo que está preguntando depende completamente tanto de la base de datos que está utilizando como del marco que está utilizando para comunicarse con su base de datos.

Si está usando algo como Hibernate como su capa de persistencia, tiene un conjunto de escuchas e interceptores que puede usar para monitorear los registros que entran y salen de la base de datos.

Answer 8

Hay algunas técnicas diferentes aquí, dependiendo de la base de datos que estés usando. Una idea es sondear la base de datos (que estoy seguro de que estás tratando de evitar). Básicamente, puedes revisar los cambios de vez en cuando.

Otra solución (si está utilizando SQL Server 2005) es usar Notification Services, aunque esta tecnología se supone que será reemplazada en SQL 2008 (aún no hemos visto un reemplazo puro, pero Microsoft ha hablado de ello públicamente) .

Answer 9

Si está utilizando Oracle, consulte esta publicación anterior .

Answer 10

Esto suele ser lo que hace la aplicación cliente / servidor estándar. Si todas las inserciones / actualizaciones / eliminaciones pasan por la aplicación del servidor, que luego modifica la base de datos, las aplicaciones cliente pueden descubrir mucho más fácilmente qué cambios se hicieron.

Answer 11

Si está utilizando postgresql, tiene la capacidad de escuchar notificaciones del cliente JDBC .

Answer 12

Sugeriría usar una columna de marca de tiempo, actualizada por última vez, junto con posiblemente el usuario actualizando el registro, y luego permitir que los clientes verifiquen su marca de tiempo del registro local con la del registro persistido.

La complejidad añadida de agregar una funcionalidad de devolución de llamada / activación simplemente no vale la pena en mi opinión, a menos que sea compatible con la base de datos y la biblioteca cliente utilizada, como por ejemplo los servicios de notificación ofrecidos para SQL Server 2005 utilizados junto con ADO. NET.