Oracle中的观察者模式 [英] Observer pattern in Oracle

问题描述

我可以在表中更改或添加一些行时设置钩子，并在此类事件发生时得到通知吗？我发现网络，只有管道粘住。但是没有办法在发送时立即获取管道消息。只有定期尝试接收。

Can I set hook on changing or adding some rows in table and get notified someway when such event araised? I discover web and only stuck with pipes. But there is no way to get pipe message immediately when it was send. Only periodical tries to receive.

推荐答案

通常应避免从数据库实现观察者模式。

Implementing an Observer pattern from a database should generally be avoided.

为什么？它依赖于供应商专有（非标准）技术，促进数据库供应商锁定和支持风险，并导致一点膨胀。从企业的角度来看，如果不是以受控的方式完成，它可以看起来像skunkworks - 以不寻常的方式实现应用程序和集成模式和工具通常覆盖的行为。如果在细粒度级别上实现，则可能导致与微小数据变化的紧耦合，以及大量不可预测的通信和处理，从而影响性能。机器中的额外cog可能是一个额外的断点 - 它可能对O / S，网络和安全配置敏感，或者在供应商技术中可能存在安全漏洞。

Why? It relies on vendor proprietary (non-standard) technology, promotes database vendor lock-in and support risk, and causes a bit of bloat. From an enterprise perspective, if not done in a controlled way, it can look like "skunkworks" - implementing in an unusual way behaviour commonly covered by application and integration patterns and tools. If implemented at a fine-grained level, it can result in tight-coupling to tiny data changes with a huge amount of unpredicted communication and processing, affecting performance. An extra cog in the machine can be an extra breaking point - it might be sensitive to O/S, network, and security configuration or there may be security vulnerabilities in vendor technology.

如果您观察由您的应用管理的事务数据：

If you're observing transactional data managed by your app:

• 在您的应用中实现Observer模式。例如。在Java中，CDI和javabeans规范直接支持这一点，并且根据Gang Of Four的OO自定义设计是一个完美的解决方案。


• 可选地向其他应用程序发送消息。

如果用户正在直接修改主数据，则可以使用过滤器/拦截器，MDB消息，CDI事件和Web服务。数据库，然后：

If users are directly modifying master data within the database, then either:

• 在应用程序中提供单个管理页面，以控制主数据刷新或


• 提供单独的主数据管理应用程序并向相关应用程序发送消息


• （最佳方法）在质量（评论，测试等）

如果你观察到事务性的由另一个应用程序管理的数据（共享数据库集成）或您使用数据级集成（如ETL）为您的应用程序提供数据：

If you're observing transactional data managed by another app (shared database integration) OR you use data-level integration such as ETL to provide your application with data:

• 轮询分阶段/ ETL控制表以了解何时/何时发生更改或


• 使用用于通知或轮询的JDBC / ODBC级专有扩展，以及Alex Poole的回答或


• 重构将2个应用程序的数据操作重叠到共享SOA服务中可以避免观察要求或将其从数据操作提升到更高级别的SOA /应用程序消息


• 使用ESB或数据库适配器调用应用程序进行通知，或调用WS端点进行批量数据传输例如Apache


• 避免使用数据库扩展基础设施，例如管道或高级排队

• try to have data entities written by just one app (read-only by others)
• poll staging/ETL control table to understand what/when changes occured OR
• use JDBC/ODBC-level proprietary extension for notification or polling, as well mentioned in Alex Poole's answer OR
• refactor overlapping data operations from 2 apps into a shared SOA service can either avoid the observation requirement or lift it from a data operation to a higher level SOA/app message
• use an ESB or a database adapter to invoke your application for notification or a WS endpoint for bulk data transfer (e.g. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
• avoid use of database extension infrastructure such as pipes or advanced queuing

如果您使用消息传送（发送或接收），请从您的应用程序。来自DB的消息是一个反模式。作为最后一种手段，可以使用调用Web服务的触发器（ http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ），但是需要非常仔细地以非常粗略的方式执行此操作，调用业务（子）处理当一组数据改变时，而不是碾碎细粒度的CRUD类型操作。最好触发一个工作，并让该工作调用该事务外的Web服务。

If you use messaging (send or recieve), do so from your application(s). Messaging from the DB is a bit of an antipattern. As a last resort, it is possible to use triggers which invoke web services (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html), but great care is required to do this in a very coarse fashion, invoking a business (sub)-process when a set of data changes, rather than crunching fine-grained CRUD type operations. Best to trigger a job and have the job call the web service outside the transaction.

这篇关于Oracle中的观察者模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！