Obtenir des événements d'une base de données
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 à triggers . En gros, il semble que les déclencheurs offrent ce type de fonctionnalité:
(de Wikipedia )
Il y a généralement trois événements déclencheurs qui provoquent "l'activation" des déclencheurs:
- Événement INSERT (lorsqu'un nouvel enregistrement est inséré dans la base de données).
- Événement UPDATE (lorsqu'un enregistrement est en cours de modification).
- DELETE (un enregistrement est en cours de suppression).
Ma question est la suivante: y a-t-il un moyen que je puisse être averti en Java (incluant de préférence les données qui ont changé) par la base de données lorsqu'un enregistrement est mis à jour/supprimé/inséré à l'aide d'une sorte de sémantique de déclencheur?
Quelles pourraient être quelques solutions alternatives à ce problème? Comment puis-je écouter les événements de 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).
Disons qu'un client modifie un enregistrement de la base de données qui intéresse tous les 5 des clients. J'essaie de trouver des moyens pour que les clients soient "avertis" du changement (de préférence avec les données affectées en pièce jointe) au lieu de les interroger pour les données à un certain intervalle.
À l'aide d'Oracle, vous pouvez configurer un déclencheur sur une table, puis lui faire envoyer un message 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 pousser les modifications vers 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), j'ai des déclencheurs dans H2 qui publient des événements de modification à l'aide de JMX.
Ne mélangez pas la base de données (qui contient les données) et les événements sur 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 certaines choses se produisent - par exemple, à un sujet JMS.
Les déclencheurs sont un dernier recours, car vous travaillez alors sur des éléments relationnels plutôt que sur des "événements" sur les données. (Par exemple, une "mise à jour" pourrait en réalité correspondre à un événement "société ayant changé de nom légal") Si vous vous fiez à la base de données, vous devrez mapper les insertions et les mises à jour sur des événements réels .... qui tu savais déjà!
Vous pouvez ensuite superposer d'autres éléments sur ces notifications, comme le traitement du flux d'événements, pour rechercher les événements qui intéressent les autres.
James
Hmm. Vous utilisez donc PostgreSQL et vous voulez "écouter" les événements et être "avertis" lorsqu'ils se produisent?
http://www.postgresql.org/docs/8.3/static/sql-listen.htmlhttp://www.postgresql.org/docs/8.3/static/sql-notify.html
J'espère que cela t'aides!
L'appel de processus externes depuis 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 à partir de déclencheurs,
postgresql peut appeler des fonctions C arbitraires chargées dynamiquement,
MySQL peut appeler des fonctions C arbitraires, mais elles doivent être compilées,
Sybase peut effectuer des appels système si cela est configuré.
Je pense que vous confondez deux choses. Ils sont tous deux très spécifiques au fournisseur de base de données.
La première, 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 j'appellerai "les é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 qu'il y a des mises à jour de la base de données des clients, 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 mettre cela 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 une autre implémentation de ceci.
J'irais même 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.
La solution la plus simple consiste à faire en sorte que les déclencheurs insert/update/delete 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.
Si vous utilisez postgresql, il est capable d'écouter notifications à partir du client JDBC.
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 en tant que couche de persistance, vous disposez d'un ensemble d'écouteurs et d'intercepteurs que vous pouvez utiliser pour surveiller les enregistrements entrant et sortant de la base de données.
Il existe différentes techniques selon la base de données utilisée. 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, mais Microsoft en a parlé publiquement).
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.
Si vous utilisez Oracle, consultez cet message précédent .