Discussion :

[mikina]

Bonjour à tous,

J'aimerais savoir s'il paraît possible, via l'API JDBC, de détecter qu'une donnée ait été modifiée au sein d'un SGBD client ???? (Sans que l'on ait besoin de faire des manips dans le SGBD client, exemple : trigger sur chaque update, delete, insert etc.)

Merci pour les infos en retour

[Népomucène]

Cela dépend du SGBD.
C'est quoi comme serveur ?

[mikina]

Prenons le cas d'oracle si tu veux bien !

[Népomucène]

Aïe, je le connais mal On va chercher une piste par analogie...

Dans SQL Server, il existe une fonction CHECKSUM qui calcule une valeur binaire représentant un ensemble de données d'une table.
Si je veux détecter des changements dans cette table, j'utilise cette fonction dans une requête du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT   CHECKSUM_AGG(BINARY_CHECKSUM(*)) As Controle
FROM   Products

Chaque fois que des ajouts/modif/suppr sont effectués dans la table, la valeur de Controle est changée.

Je suppose qu'il doit exister une fonction similaire dans Oracle.
C'est facile à mettre en place mais il faut faire une requête par table à surveiller (à moins que Oracle possède une super fonction qui surveille tout).

[mikina]

Merci pour l'info !
Ceci dit cette commande, peut-elle être utilisé coté Java via le JDBC ?

[Népomucène]

Oui puisque Java transmettra la requête "tel quel"
Attention, vérifie que ce type de fonction est dispo dans Oracle.

[_skip]

Et si la table contient 5 millions d'enregistrement c'est lent?

[Népomucène]

Dans une table de 5 millions d'enregistrements, il y a certainement un champ de type DATE qui enregistre la création ou la modification

Dans SQL Server, il y a une ruse qui consiste à ne regarder que la date récente.
Cela donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT   CHECKSUM_AGG(BINARY_CHECKSUM(*)) As Controle
FROM   Products WHERE DateMaj > GETDATE()-1

[mikina]

Lent ou pas lent, peu importe pour le moment !
En tout cas c'est une très bonne nouvelle Népomucène
Mais sais-tu si je peux suite à un changement localiser et recueillir la nouvelle info ?? ... Toujours dans l'optique de passer via le JDBC (et sans bricoler dans la mesure du possible le SGBD client).

[Baptiste Wicht]

Lent ou pas lent, peu importe pour le moment !
En tout cas c'est une très bonne nouvelle Népomucène
Mais sais-tu si je peux suite à un changement localiser et recueillir la nouvelle info ?? ... Toujours dans l'optique de passer via le JDBC (et sans bricoler dans la mesure du possible le SGBD client).

Tu peux tester les enregistrements un par un avec checksum. Par contre, ça risque d'être lent, peut-être qu'Oracle a quelque chose qui permet d'identifier les changements.

[Népomucène]

Bon, comme a dit Baptiste, le checksum est très souple. Il peut être utilisé pour un ou plusieurs champs d'un enregistrement, ou d'un ensemble d'enregistrements ou de la table entière ; voire même d'une vue (cad plusieurs tables).

Dans cette optique, je ne pense pas que Java soit adapté à ton problème détection de tous les changements dans une base de données.
La solution du Checksum est une solution qui vient du serveur de base de données (SQL Server dans mon exemple) et non de Java.
Java se contente de récupérer les informations venant du serveur via une requête.

Donc, pour être efficace, MIKINA, et en dépit du grand plaisir que j'ai à étaler ma science du checksum , il vaut mieux que tu continues ce post dans le forum Oracle où tu trouvera probablement quelqu'un qui t'indiquera une fonction équivalente si elle existe.

Maintenant, comme j'ai l'impression que tu souhaites avoir une liste des modifications apportées, il faudra tout de même probablement passer par des triggers pour journaliser ces modifs dans une table.

à moins que, ... à moins que, ...
si, tu ne t'intéresse qu'à une petite table du genre liste d'utilisateurs (moins de 500 enregistrements par exemple) alors on peut envisager de créer une "image" de la table dans un Arraylist qui serait comparé périodiquement à la table dans Oracle.

Comme tu le vois, il faut maintenant que tu nous dise précisément ce que tu veux surveiller dans la base pour qu'on puisse te donner une vraie piste de recherche.

[mikina]

Désolé d'avoir tardé à répondre cher Népomucène !

Avant tout, j'ai tenté d'avoir des infos en ouvrant un topic sous Oracle (il est toujours bon de croiser les infos) ... Mais apparemment, les aficionados d'Oracle n'ont pas souhaité répondre . Peut être que la presentation de mon problème n'a pas été suffisamment claire ...

Maintenant, je vais tenter d'être plus précis sur ce que je veux faire !
Je cherche à pouvoir exporter d'un SGDB les modifications qui ont été réalisées.
Et il m'intéresserait d'utiliser Java pour cela (sans réellement savoir si cela est possible). Donc concretement, ce serait faire une appli capable de se connecter à un SGBD ou à une partie du SGBD pour récupérer, par exemple, qu'un user lambda a effectué un update dans telle table sur tel champ.
L'idéal serait de trouver un fichier système qui stocke l'historique des commandes réalisées par les users et de pouvoir extraire les infos via une méthode, objet ou autre (paramétré par moi-même).
Je suis parti avec l'idée de me restreindre à Oracle pour commencer mais je chercherais à vouloir l'étendre à d'autres SGBD ! Donc même les infos, sur SQL Server m'intéresse grandement
Y avait-il une autre question ? ... En tout cas, merci.

[Népomucène]

La réponse théorique est l'analyse du journal de transaction.
Oracle, SQL Server et les autres ont tous un journal dans lequel est enregistrée la moindre demande de chaque utilisateur.
Donc si on arrive à lire le journal, on sait ce qu'il se passe dans la base (d'ailleurs c'est valable aussi dans le monde réel )

Dans le pratico-pratique, ça se gâte car le résultat de la lecture du journal de transaction de SQL Server avec SELECT * FROM ::fn_dblog(null, null) nous donne un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
00007ffb:0000006f:0001  LOP_BEGIN_CKPT    LCX_NULL       0000:00000000      0000         96                    00007ffb:0000006d:0001

... et là je n'ai copié que le début.

Il existe des outils (payants) pour interpréter le journal

Donc (à la différence du monde réel) la lecture du journal ne m'a rien apporté.

De mon point de vue, ce que tu cherches se situe dans la capacité du SGBD à donner en clair des informations sur les transactions
(pour SQL Server c'est pas gagné) et non dans le langage (java, .net, ...) que tu vas utiliser pour accéder à ces informations.

Si tu trouves une solution pour SQL Server, je suis intéressé (avec tous ceux qui ont cherché à utiliser fn_dblog).

Bon courage ...

[mikina]

Bon, je sens que la tache va être ardue
Si apparemment, le fichier des transactions effectuée à la gueule de la ligne que tu m'as envoyée ... je me demande en effet comment je vais réussir à l'exploiter ! A ce propos, pourrais-tu me fournir une vue plus large du contenu de ce fichier ? J'entends plus qu'une seule ligne ! ... Sais tu de quelle nature est le format du fichier ? Texte ? ou autre ...

[tchize_]

faudrait déjà connaitre les besoin client qui se trouve derrière ta demande. Parce que, comme elle est décrite, tu veux savoir ce qu'à fait un user lambda à la base de donnée sur une période de temps donnée. Hors c'est le genre de truc que tu va obtenir via les outils d'administration de la base de données (ici, si je vais voir nos DBA et que je dit "tu peux me dire ce que l'application xxxx fait en ce moment), il sont capable de me sortir toutes les requetes sql envoyées. Présenté comme tu le fait, je vois pas trop l'intéret d'aller faire ça en java alors que les outils de la bae de données le font déjà.

[mikina]

Je ne doute pas une seule seconde que les outils d'admin du SGBD puissent t'informer sur les requêtes réalisées !
J'aimerais outrepasser le fait de solliciter manuellement les outils d'admin, soit faire une application "automatique" capable de créer un flux pour véhiculer (un cas simple, exemple un update).

[tchize_]

si tu nous disias déjà quel est le besoin (là tu nous décrit le moyen dont tu voudrais disposer). Si tu veux savoir si un row a été updaté avant de le sauver, utiliser une colonne verions que tu met constamment à jour. Ainsi tu peux faire des choses genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

update table machin set ...... where machinId=? and version=?

Si t'as 0 row updaté, c'est que t'as de la concurrence, tu fait ton rollback et t'agit en conséquence. En oracle tu peux meme faire des triggers qui mettent version à jour automatiquement.

[Népomucène]

A ce propos, pourrais-tu me fournir une vue plus large du contenu de ce fichier ? J'entends plus qu'une seule ligne ! ... Sais tu de quelle nature est le format du fichier ? Texte ? ou autre ...

Il s'agit du résultat de la requête dans l'analyseur de requête de SQL Server (affiché à l'écran et j'ai fait un copié/collé).
Les autres lignes sont du même tonneau. Pour information fn_dblog est une fonction NON documentée. Donc on est déjà dans la bidouille.

Bon, mikina, si je résume bien ton propos, tu cherches une solution pour :
- une solution qui enregistre toute modification dans une base de données.
- solution qui doit fonctionner pour n'importe quelle base de données.

A l'évidence, il faut rappeler qu'un driver JDBC, tel que défini par SUN doit en gros :
- assurer la connexion avec la base.
- donner des informations sur la structure des tables (liste des tables, liste des champs avec leur nature, etc.) cad des méta-données.
- permettre le CRUD (create, retrieve, update, delete).

La responsabilité de la création concrète du JDBC incombe à celui qui a créé la base de données.
Par exemple le JDBC de SQL Server est fait et maintenu par Microsoft ET NON par SUN.
Idem pour les autres bases ORACLE, PostGre, etc.

En conséquence donner des informations sur les transactions dépend uniquement
du bon vouloir de chaque éditeur de SGBD car ce n'est nullement exigé par JDBC.

Peut-être n'ai-je pas assez creusé la question mais il me semble que développer un tel produit en Java, nécessite un connaissance approfondie de chaque SGBD. Ce serait forcément projet de très grande ampleur difficile à maintenir. Le réussir sur un ou deux SGBD serait déjà très bien.