A implementação de um padrão Observer de um banco de dados geralmente deve ser evitada.

Por quê? Ele se baseia na tecnologia proprietária do fornecedor (não padrão), promove o aprisionamento do fornecedor de banco de dados e oferece suporte ao risco e causa um pouco de inchaço. Do ponto de vista corporativo, se não for feito de maneira controlada, pode parecer "skunkworks" - implementando de maneira incomum um comportamento comumente coberto por aplicativos e padrões e ferramentas de integração. Se implementado em um nível de granularidade fina, pode resultar em um acoplamento rígido a pequenas alterações de dados com uma enorme quantidade de comunicação e processamento imprevisíveis, afetando o desempenho. Uma engrenagem extra na máquina pode ser um ponto de ruptura extra - pode ser sensível ao sistema operacional, rede e configuração de segurança ou pode haver vulnerabilidades de segurança na tecnologia do fornecedor.

Se você estiver observando dados transacionais gerenciados pelo seu aplicativo:

• implementar o padrão Observer em seu aplicativo. Por exemplo. Em Java, as especificações CDI e javabeans suportam isso diretamente, e o design personalizado OO de acordo com o livro Gang Of Four é uma solução perfeita.
• opcionalmente, envie mensagens para outros aplicativos. Filtros/interceptores, mensagens MDB, eventos CDI e serviços web também são úteis para notificação.

Se os usuários estiverem modificando diretamente os dados mestre no banco de dados, então:

• forneça uma página de administração única em seu aplicativo para controlar a atualização dos dados mestre OU
• forneça um aplicativo de gerenciamento de dados mestre separado e envie mensagens para aplicativos dependentes OU
• (melhor abordagem) gerencie edições de dados mestres em termos de qualidade (revisões, testes etc.) e tempo (trate o mesmo que alteração de código), promova por meio de ambientes, implante e atualize dados / reinicie o aplicativo para um cronograma gerenciado

Se você estiver observando dados transacionais gerenciados por outro aplicativo (integração de banco de dados compartilhado) OU usar integração em nível de dados, como ETL, para fornecer dados ao seu aplicativo:

• tente ter entidades de dados gravadas por apenas um aplicativo (somente leitura por outros)
• poll staging/tabela de controle ETL para entender quais/quando as alterações ocorreram OU
• use a extensão proprietária de nível JDBC/ODBC para notificação ou pesquisa, conforme mencionado na resposta de Alex Poole OU
• refatorar operações de dados sobrepostas de dois aplicativos em um serviço SOA compartilhado pode evitar o requisito de observação ou elevá-lo de uma operação de dados para uma mensagem SOA/aplicativo de nível superior
• use um ESB ou um adaptador de banco de dados para chamar seu aplicativo para notificação ou um endpoint WS para transferência de dados em massa (por exemplo, Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
• evite o uso de infraestrutura de extensão de banco de dados, como pipes ou enfileiramento avançado

Se você usa mensagens (enviar ou receber), faça-o em seu(s) aplicativo(s). As mensagens do banco de dados são um pouco antipadrão. Como último recurso, é possível usar gatilhos que invocam serviços da web (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), mas é necessário muito cuidado para fazer isso de maneira muito grosseira, invocando um (sub)processo de negócios quando um conjunto de dados é alterado, em vez de processar operações do tipo CRUD refinadas. É melhor acionar um trabalho e fazer com que o trabalho chame o serviço da Web fora da transação.