Discussion :

[mugwump]

Bonjour,

Dans le cadre d'un projet, j'ai besoin de synchroniser (de façon bi-directionnelle et si possible instantannée) des informations depuis un LDAP vers différentes tables Oracle. La contrainte est que cette synchro doit se faire via une table tampon.

En clair : j'ai
LDAP <------> TAMPON_INDIV (table Oracle) <------> INDIVIDU, SOCIETE,....(tables Oracle)
Bien sur, il y aura dénormalisation et ce n'est pas l'idéa, mais il faut faire avec.

une donnée mise à jour dans le LDAP doit arriver in fin dans mes table INDIVIDU,...
A l'inverse, une donnée mise à jour dans la table INDIVDU doit arriver dans le LDAP.

Avec-vous une idée de la solution satisfaisante ?
Les triggers sont-ils une bonne solution ? Eviter des appels récursifs doit avec ces triggers ne va-t-il pas rendre complexe cette solution ?
Y'-t-a il UNE solution idéal ?

Merci
Mugwump

[NGasparotto]

Et le LDAP, c'est quoi ? Une autre BD Oracle ?

Nicolas.

[mugwump]

Bonjour,

Non, il s'agit d'un LDAP Critical Path.
en clair, j'ai deux solutions :
- une syncrho bi-directionnelle et instannée avec des triggers dans tous les sens => je me demande si cela ne va pas être l'usine à gaz.
- une synchro non-instannée ou deux proc stock. pourraient s'exécuter toutes les 30 secondes.L'une met à jour dans un sens, et l'autre dans l'autre sens.

D'autres idées ?

Mugwump

[dyvim]

Je pense que ça va surtout dépendre si tu peux créer des triggers sur ton LDAP qui accèdent à ta base Oracle et inversement...
Parce que sinon il ne te reste que ta deuxième solution... qui pourrait bien se transformer en batchs au lieu des procédures stockées...

[mugwump]

Je pense que ça va surtout dépendre si tu peux créer des triggers sur ton LDAP qui accèdent à ta base Oracle et inversement...
Parce que sinon il ne te reste que ta deuxième solution... qui pourrait bien se transformer en batchs au lieu des procédures stockées...

Dans ce cas, mon problème est le suivant : Comment gérer, entre l'éxecution des deux batchs (j'imagine que tu veux dire jobs ?),
- si une ligne de la table TAMPON_INDIV est mis à jour pour un individu donné et que
- la table INDIVIDU est mis à jour pour le même individu (cela peut arriver).

Lors de la prochaine exécution de l'un des batchs, celui-ci risque de mettre à jour une table alors qu'un update plus récent était réalisé sur l'autre table.


mugwump