为什么？它依赖于供应商专有(非标准)技术,促进数据库供应商锁定和支持风险,并导致一些膨胀.从企业的角度来看,如果不是以受控的方式完成,它可能看起来像“skunkworks” – 以一种不寻常的方式实现应用程序和集成模式和工具通常涵盖的行为.如果在细粒度级别实现,则可能导致与微小数据更改的紧密耦合,同时存在大量不可预测的通信和处理,从而影响性能.机器中的额外齿轮可能是一个额外的突破点 – 它可能对O / S,网络和安全配置很敏感,或者供应商技术中可能存在安全漏洞.
如果您正在观察应用管理的交易数据：
>在您的应用中实施Observer模式.例如.在Java中,CDI和javabeans规范直接支持这一点,根据Gang Of Four书的OO定制设计是一个完美的解决方案.
>可选择向其他应用发送消息.过滤器/拦截器,MDB消息,CDI事件和Web服务对通知也很有用.
>在您的应用程序中提供单一的管理页面来控制主数据刷新OR
>提供单独的主数据管理应用程序并将消息发送到从属应用程序或
>(最佳方法)在质量(评论,测试等)和时间(与代码更改相同)方面管理主数据编辑,通过环境进行推广,部署和刷新数据/重新启动应用程序到托管模块
如果您正在观察由另一个应用程序管理的事务数据(共享数据库集成),或者您使用数据级集成(如ETL)为您的应用程序提供数据：
>尝试让数据实体只由一个应用程序编写(其他人只读)
> poll staging / ETL控制表,了解发生了什么/何时发生了更改OR
>使用JDBC / ODBC级专有扩展进行通知或轮询,在Alex Poole的回答中也提到了
>重构从2个应用程序到共享SOA服务的重叠数据操作可以避免观察要求或将其从数据操作提升到更高级别的SOA /应用程序消息
>使用ESB或数据库适配器调用应用程序进行通知,或使用WS端点进行批量数据传输(例如Apache Camel,Apache ServiceMix,Mule ESB,Openadaptor)
>避免使用数据库扩展基础结构,例如管道或高级排队
如果您使用消息(发送或接收),请从您的应用程序执行此操作.来自DB的消息传递有点像反模式.作为最后的手段,可以使用调用Web服务的触发器(http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html),但需要非常小心地以非常粗略的方式执行此操作,在一组数据更改时调用业务(子)进程,而不是处理细粒度CRUD类型的操作.最好触发作业并让作业在事务之外调用Web服务.
