syncrhronisation entre différentes tables Oracle

Version imprimable

03/07/2009, 23h12
mugwump

syncrhronisation entre différentes tables Oracle

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
05/07/2009, 17h49
NGasparotto

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

Nicolas.
06/07/2009, 14h15
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
16/07/2009, 16h16
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...
18/07/2009, 11h57
mugwump

Citation:

Envoyé par 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...

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