java - programacion - Obtener eventos de una base de datos
manual de programacion android pdf (12)
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 desencadenar . Básicamente, parece que los desencadenantes ofrecen este tipo de funcionalidad:
(de Wikipedia )
Normalmente hay tres eventos desencadenantes que provocan desencadenantes para "disparar":
- Evento INSERT (como un nuevo registro se está insertando en la base de datos).
- Evento ACTUALIZAR (como un registro se está cambiando).
- Evento DELETE (mientras se borra un registro).
Mi pregunta es: ¿hay alguna forma en que se me pueda notificar en Java (preferiblemente incluyendo los datos que cambiaron) la base de datos cuando se actualiza / elimina / inserta un registro 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 todas en diferentes procesos / existentes en diferentes PC. Todos comparten una base de datos común (Postgres en este caso).
Digamos que un cliente cambia un registro en el DB que los 5 clientes están "interesados". Estoy tratando de pensar en maneras de que los clientes sean "notificados" del cambio (preferiblemente con los datos afectados adjuntos) en lugar de ellos preguntando por los datos en algún intervalo.
Aquí hay algunas técnicas diferentes según la base de datos que esté utilizando. Una idea es sondear la base de datos (que estoy seguro que estás tratando de evitar). Básicamente, puedes verificar los cambios cada cierto tiempo.
Otra solución (si está utilizando SQL Server 2005) es usar Notification Services, aunque supuestamente esta tecnología está siendo reemplazada en SQL 2008 (aún no hemos visto un reemplazo puro, pero Microsoft lo ha hablado públicamente).
Creo que estás confundiendo dos cosas. Ambos son altamente específicos del proveedor de db.
Lo primero que llamaré "desencadenantes". Estoy seguro de que hay al menos un proveedor de DB que piensa que los desencadenantes son diferentes a esto, pero tengan paciencia conmigo. Un disparador es una pieza de código del lado del servidor que se puede adjuntar a la tabla. Por ejemplo, podría ejecutar un procedimiento almacenado PSQL en cada actualización en la tabla X. Algunas bases de datos le permiten escribir estos en lenguajes de programación reales, otros solo en su variante de SQL. Los desencadenantes suelen ser razonablemente rápidos y escalables.
El otro lo llamaré "eventos". Estos son desencadenantes que se activan en la base de datos que le permiten definir un controlador de eventos en su programa cliente. IE, cada vez que hay actualizaciones en la base de datos de clientes, activa updateClientsList en tu programa. Por ejemplo, usando 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 oráculo? Los servicios de notificación MSSQL, mencionados en otra respuesta, son otra implementación de esto también.
Me atrevería a decir que es mejor que realmente sepa por qué quiere que la base de datos notifique a su programa de cliente, de lo contrario, debe seguir con los factores desencadenantes del lado del servidor.
Esto es usualmente para lo que es 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, entonces las aplicaciones del cliente pueden descubrir mucho más fácilmente qué cambios se realizaron.
Hmm. ¿Entonces está usando PostgreSQL y quiere "escuchar" los eventos y ser "notificado" cuando ocurran?
http://www.postgresql.org/docs/8.3/static/sql-listen.html http://www.postgresql.org/docs/8.3/static/sql-notify.html
¡Espero que esto ayude!
Llamar a procesos externos desde la base de datos es muy específico del vendedor.
Justo al lado de la parte superior de mi cabeza:
SQLServer puede llamar a programas CLR desde disparadores,
postgresql puede invocar funciones C arbitrarias cargadas dinámicamente,
MySQL puede invocar funciones C arbitrarias, pero deben compilarse en,
Sybase puede hacer llamadas al sistema si está configurado para hacerlo.
Lo más simple es hacer que los disparadores insert / update / delete hagan una entrada en alguna tabla de registro, y hacer que su programa java controle esa tabla. Las buenas columnas para tener en su 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 100K de registros, eso probablemente sea suficiente.
Lo que está pidiendo depende completamente de la base de datos que está utilizando y del marco que está utilizando para comunicarse con su base de datos.
Si está utilizando algo como Hibernate como capa de persistencia, tiene un conjunto de oyentes e interceptores que puede usar para supervisar los registros que entran y salen de la base de datos.
No mezcle la base de datos (que contiene los datos) y los eventos en esos datos.
Los desencadenantes son de una sola manera, pero normalmente tendrá una capa de persistencia en su aplicación. Esta capa puede elegir disparar eventos cuando suceden ciertas cosas, por ejemplo, en un tema JMS.
Los desencadenantes son una última zanja, ya que estás operando con elementos relacionales en lugar de "eventos" en los datos. (Por ejemplo, una "actualización", en realidad podría asignarse a un evento de "nombre legal cambiado de empresa"). Si depende de la base de datos, tendrá que asignar los insertos y actualizaciones a eventos de la vida real ... que ¡usted ya lo sabía!
A continuación, puede superponer otras cosas sobre estas notificaciones, como el procesamiento de la secuencia de eventos, para buscar eventos que les interesan a los demás.
James
Si está utilizando Oracle, consulte esta publicación anterior .
Si está utilizando postgresql, tiene la capacidad de escuchar notifications del cliente JDBC.
Sugeriría utilizar una columna de marca de tiempo, actualizada por última vez, junto con posiblemente el usuario actualizando el registro, y luego dejar que los clientes verifiquen su marca de tiempo de registro local contra la del registro persistente.
La complejidad añadida de agregar una función de devolución de llamada / desencadenador simplemente no vale la pena en mi opinión, a menos que sea compatible con el servidor de base de datos y la biblioteca del cliente utilizada, como por ejemplo los servicios de notificación ofrecidos para SQL Server 2005 junto con ADO.NET.
Usando Oracle puede configurar un Disparador en una tabla y luego hacer que el desencadenador 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 usado este método para enviar cambios a mi aplicación frente a la encuesta. Si está utilizando una base de datos Java (H2), tiene opciones adicionales. En mi aplicación actual (SIEM) tengo desencadenantes en H2 que publican eventos de cambio usando JMX.