Por lo general, se debe evitar implementar un patrón Observer desde una base de datos.
¿Por qué? Se basa en tecnología patentada (no estándar) del proveedor, promueve el bloqueo del proveedor de la base de datos y el riesgo de soporte, y provoca un poco de hinchazón. Desde una perspectiva empresarial, si no se hace de manera controlada, puede parecer "skunkworks", implementando de una manera inusual un comportamiento comúnmente cubierto por herramientas y patrones de aplicaciones e integración. Si se implementa en un nivel de granularidad fina, puede resultar en un acoplamiento estrecho a pequeños cambios de datos con una gran cantidad de comunicación y procesamiento imprevistos, lo que afecta el rendimiento. Un engranaje adicional en la máquina puede ser un punto de ruptura adicional:puede ser sensible a la configuración del sistema operativo, la red y la seguridad, o puede haber vulnerabilidades de seguridad en la tecnología del proveedor.
Si está observando datos transaccionales administrados por su aplicación:
- implemente el patrón Observer en su aplicación. P.ej. En Java, las especificaciones de CDI y javabeans admiten esto directamente, y el diseño personalizado OO según el libro Gang Of Four es una solución perfecta.
- opcionalmente, envíe mensajes a otras aplicaciones. Los filtros/interceptores, los mensajes MDB, los eventos CDI y los servicios web también son útiles para las notificaciones.
Si los usuarios modifican directamente los datos maestros dentro de la base de datos, entonces:
- proporcione una página de administración única dentro de su aplicación para controlar la actualización de datos maestros O
- proporcionar una aplicación de administración de datos maestros separada y enviar mensajes a aplicaciones dependientes O
- (mejor enfoque) administrar ediciones de datos maestros en términos de calidad (revisiones, pruebas, etc.) y tiempo (tratarlo igual que el cambio de código), promocionar a través de entornos, implementar y actualizar datos/reiniciar la aplicación a un cronograma administrado
Si está observando datos transaccionales administrados por otra aplicación (integración de base de datos compartida) O utiliza integración a nivel de datos como ETL para proporcionar datos a su aplicación:
- intentar que las entidades de datos sean escritas por una sola aplicación (solo lectura por otras)
- escenario de la encuesta/tabla de control de ETL para comprender qué/cuándo ocurrieron los cambios O
- use la extensión propietaria de nivel JDBC/ODBC para notificaciones o encuestas, como también se menciona en la respuesta de Alex Poole O
- refactorizar operaciones de datos superpuestas de 2 aplicaciones en un servicio SOA compartido puede evitar el requisito de observación o elevarlo de una operación de datos a un mensaje SOA/aplicación de nivel superior
- utilice un ESB o un adaptador de base de datos para invocar su aplicación para recibir notificaciones o un punto final de WS para la transferencia masiva de datos (por ejemplo, Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- evite el uso de la infraestructura de extensión de la base de datos, como canalizaciones o colas avanzadas
Si usa mensajería (enviar o recibir), hágalo desde su(s) aplicación(es). La mensajería desde la base de datos es un poco antipatrón. Como último recurso, es posible utilizar activadores que invoquen servicios web (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), pero se requiere mucho cuidado para hacer esto de una manera muy tosca, invocando un (sub) proceso comercial cuando cambia un conjunto de datos, en lugar de procesar operaciones de tipo CRUD de grano fino. Lo mejor es desencadenar un trabajo y hacer que el trabajo llame al servicio web fuera de la transacción.
