Obtenir des événements d'une base de données

Question

Je ne connais pas très bien les bases de données et leur offre en dehors des opérations CRUD.

Mes recherches m'ont conduit à des déclencheurs . En gros, il semble que les déclencheurs offrent ce type de fonctionnalité:

  

(extrait de Wikipedia )

     

Trois événements déclencheurs sont généralement à l’origine du déclenchement du déclencheur: "feu":

     

  
• événement INSERT (lorsqu'un nouvel enregistrement est inséré dans la base de données).
  
• Evénement UPDATE (lorsqu'un enregistrement est en cours de modification).
  
• événement DELETE (lorsqu'un enregistrement est en cours de suppression).
  

Ma question est la suivante: la base de données peut-elle me prévenir en Java (de préférence en incluant les données qui ont changé) lorsqu'un enregistrement est mis à jour / supprimé / inséré à l'aide d'une sorte de sémantique de déclencheur?

Quelles pourraient être d’autres solutions à ce problème? Comment puis-je écouter les événements de la base de données?

La raison principale pour laquelle je souhaite procéder est un scénario de ce type :

J'ai 5 applications clientes dans des processus différents / existant sur différents PC. Ils partagent tous une base de données commune (Postgres dans ce cas).

Supposons qu'un client modifie un enregistrement dans la base de données indiquant que les 5 clients sont "intéressés". J'essaie de trouver des moyens pour que les clients soient "notifiés" de la modification (de préférence avec les données affectées attachées) au lieu de les interroger à intervalles réguliers.

Answer 1

À l'aide d'Oracle, vous pouvez configurer un déclencheur sur une table, puis le faire envoyer par un déclencheur JMS. Oracle a deux implémentations JMS différentes. Vous pouvez alors avoir un processus qui "écoutera" le message en utilisant le pilote JDBC. J'ai utilisé cette méthode pour appliquer les modifications apportées à mon application et les interroger. Si vous utilisez une base de données Java (H2), vous disposez d'options supplémentaires. Dans mon application actuelle (SIEM), dans H2, des déclencheurs publient des événements de modification à l'aide de JMX.

Answer 2

Ne mélangez pas la base de données (qui contient les données) et les événements associés à ces données.

Les déclencheurs sont à sens unique, mais vous aurez normalement une couche de persistance dans votre application. Cette couche peut choisir de déclencher des événements lorsque certains événements se produisent - par exemple, à un sujet JMS.

Les déclencheurs sont un dernier recours, car vous utilisez des éléments relationnels plutôt que des "événements". sur les données. (Par exemple, une "mise à jour", pourrait en réalité mapper un événement "société ayant changé de raison sociale") Si vous vous fiez à la base de données, vous devrez mapper les inserts & amp; mises à jour sur les événements de la vie réelle ... dont vous étiez déjà au courant!

Vous pouvez ensuite superposer d'autres éléments à ces notifications, comme le traitement du flux d'événements, pour rechercher les événements qui intéressent d'autres personnes.

James

Answer 3

Hmm. Vous utilisez donc PostgreSQL et vous souhaitez "écouter". pour les événements et être "notifié" quand ils se produisent?

http://www.postgresql.org/docs/8.3/ statique / sql-listen.html http://www.postgresql.org/docs/8.3/static/sql -notify.html

J'espère que ça aide!

Answer 4

L'appel de processus externes à partir de la base de données est très spécifique au fournisseur.

Juste au dessus de ma tête:

• SQLServer peut appeler des programmes CLR depuis déclencheurs,

• postgresql peut appeler du C arbitraire fonctions chargées dynamiquement,

• MySQL peut appeler des fonctions C arbitraires, mais ils doivent être compilés dans,

• Sybase peut effectuer des appels système, le cas échéant. pour le faire.

Answer 5

La solution la plus simple consiste à faire en sorte que les déclencheurs d’insertion / mise à jour / suppression fassent une entrée dans une table de journal et à ce que votre programme java surveille cette table. Les bonnes colonnes à avoir dans votre table de journal seraient des choses comme EVENT_CODE, LOG_DATETIME et LOG_MSG.

Cela est probablement suffisant, à moins que vous n'ayez besoin de très hautes performances ou de gérer 100 000 enregistrements.

Answer 6

Je pense que vous confondez deux choses. Ils sont tous deux très spécifiques au fournisseur de base de données.

Le premier que j'appellerai "déclencheurs". Je suis sûr qu’il ya au moins un fournisseur de bases de données qui pense que les déclencheurs sont différents, mais tenez compte de moi. Un déclencheur est un morceau de code côté serveur qui peut être associé à une table. Par exemple, vous pouvez exécuter une procédure stockée PSQL sur chaque mise à jour de la table X. Certaines bases de données vous permettent d'écrire celles-ci dans de vrais langages de programmation, d'autres uniquement dans leur variante de SQL. Les déclencheurs sont généralement assez rapides et évolutifs.

L’autre, je vais appeler "événements". Ce sont des déclencheurs qui se déclenchent dans la base de données et qui vous permettent de définir un gestionnaire d'événements dans votre programme client. IE, chaque fois que la base de données des clients est mise à jour, lancez updateClientsList dans votre programme. Par exemple, en utilisant python et firebird, voir http://www.firebirdsql.org/devel/python/docs/3.3.0/beyond-python-db-api.html#database-event-notification

Je pense que la suggestion précédente d'utiliser un moniteur est un moyen équivalent de le mettre en œuvre en utilisant une autre base de données. Peut-être oracle? Les services de notification MSSQL, mentionnés dans une autre réponse, constituent également une autre implémentation de ceci.

J'irais jusqu'à dire que vous feriez mieux de vraiment savoir pourquoi vous voulez que la base de données informe votre programme client, sinon vous devriez vous en tenir aux déclencheurs côté serveur.

Answer 7

Ce que vous demandez dépend entièrement de la base de données que vous utilisez et de la structure utilisée pour communiquer avec votre base de données.

Si vous utilisez quelque chose comme Hibernate comme couche de persistance, vous disposez d'un ensemble d'écouteurs et d'intercepteurs que vous pouvez utiliser pour surveiller les enregistrements entrants et sortants de la base de données.

Answer 8

Il existe quelques techniques différentes en fonction de la base de données que vous utilisez. Une idée consiste à interroger la base de données (ce que je suis sûr que vous essayez d'éviter). En gros, vous pouvez vérifier les changements de temps en temps.

Une autre solution (si vous utilisez SQL Server 2005) consiste à utiliser Notification Services, bien que cette technologie soit censée être remplacée dans SQL 2008 (nous n'avons pas encore vu de remplaçant pur, mais Microsoft en a parlé publiquement). .

Answer 9

Si vous utilisez Oracle, consultez cette publication précédente .

Answer 10

C’est généralement l’application de l’application client / serveur standard. Si toutes les insertions / mises à jour / suppressions passent par l’application serveur, qui modifie ensuite la base de données, les applications client peuvent ainsi trouver beaucoup plus facilement les modifications apportées.

Answer 11

Si vous utilisez postgresql, il peut écouter les notifications du client JDBC. .

Answer 12

Je suggérerais d'utiliser une colonne d'horodatage, mise à jour en dernier lieu, avec éventuellement l'utilisateur mettant à jour l'enregistrement, puis de laisser les clients contrôler l'horodatage de leur enregistrement local par rapport à celui de l'enregistrement conservé.

La complexité supplémentaire de l'ajout d'une fonctionnalité de rappel / déclencheur n'est tout simplement pas rentable à mon avis, sauf si elle est prise en charge par le backend de la base de données et la bibliothèque client utilisée, comme par exemple les services de notification offerts pour SQL Server 2005 utilisés avec ADO. NET.