Discussion :

[cantador]

Bonjour à tous,

Autre sujet d'inquiétude..
Je dois reprendre une ancienne appli, qui fonctionne avec 4 bases de données.
Or, l'examen des tables montre qu'une table des Utilisateurs a été créée dans les 4 bases.
et comme, rien n'a été prévu, si on se connecte à une des bases, en tant qu'admin, et que l'on modifie, ou ajoute
ou supprime un enregistrement, il faut répéter l'opération dans les trois autres bases.
ça marche bien entendu, si on est rigoureux, mais des soucis apparaissent selon les diverses interventions..
et depuis quelque temps, il y a une belle pagaille dans les données.
Bref, y a du boulot !
je me demande si un code de propagation des modifs sur ces tables pourrait convenir.
une sorte de super two phase commit qui ferait tout le travail.
mais, est-ce bien raisonnable d'écrire ce code ?
n'y a t-il pas une limite au multi bases ?
Ne serait-il pas préférable de virer toutes ces tables, d'en créer une seule dans une base à part et de faire une seule connexion
et ensuite de rediriger l'utilisateur vers le choix de la base sélectionnée.

merci de vos conseils

cantador

[escartefigue]

Après avoir vérifié les écarts entre les 4 tables, il faut n'en conserver qu'une, ou mieux en faire une nouvelle dans une base spécifique, et remplacer les accès par requête aux 4 différentes tables, par l'appel à un service unique (ou plutôt un service lecture et un service MàJ), qui centralise les différentes requêtes.

[Issam]

pourquoi 4 bases de données ?

sinon vu de loin , je dirais qu'il faut en urgence centraliser tout ce ****** et tout mettre dans une seule base de données,
ou alors mettre un système de réplication .

[SergioMaster]

Bonsoir,

bon il n'est pas toujours possible d'avoir ce que l'on veut : une seule database ou encore une autre avec les données communes !
@Issam j'ai le cas où un même logiciel sert à deux sociétés sur le même serveur il y a une base par société. Cependant c'est le même bureau d'étude pour les deux société et quand ils font des changements sur les matières par exemple cela doit être commun aux deux sociétés, le logiciel comprenant une 40 de programmes il est plus facile de faire une "réplication" des modifications/insertion/suppression de la base "de référence" vers la base de la 2° société

pour cela (merci FB 2.5) il est possible de mettre à jour une table d'une base à partir d'une autre
voici par exemple ce que j'ai mis en place pour une table ACHEMINEMENT
les triggers sont dans la base de référence , OMJBase la base de la 2nde société

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
-- ACHEMINEMENT ------------------------------------------------------------------
SET TERM ^ ;
CREATE TRIGGER AUI_ACHEMINEMENT FOR ACHEMINEMENT
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
DECLARE VARIABLE STMT VARCHAR(250); 
BEGIN 
    STMT='UPDATE OR INSERT INTO ACHEMINEMENT (CODE, LIBELLE)
     VALUES (?,?)';
 
	EXECUTE STATEMENT 
	(STMT)(NEW.CODE,NEW.LIBELLE)
	ON EXTERNAL DATA SOURCE 'localhost:OMJBase' AS USER 'SYSDBA' PASSWORD 'SG5336';
END^
SET TERM ; ^
 
SET TERM ^ ;
 
CREATE TRIGGER AD_ACHEMINEMENT FOR ACHEMINEMENT
ACTIVE AFTER DELETE POSITION 0
AS
DECLARE VARIABLE STMT VARCHAR(250); 
BEGIN 
 STMT='DELETE FROM ACHEMINEMENT WHERE CODE=?';
 EXECUTE STATEMENT (STMT)(OLD.CODE)
 ON EXTERNAL DATA SOURCE 'localhost:OMJBase' AS USER 'SYSDBA' PASSWORD 'SG5336'; 
END^
 
SET TERM ; ^

[Issam]

Bonsoir,

bon il n'est pas toujours possible d'avoir ce que l'on veut : une seule database ou encore une autre avec les données communes !
@Issam j'ai le cas où un même logiciel sert à deux société sur le même serveur il y a une base par société. Cependant c'est le même bureua d'étude pour les deux société et quand ils font des changements sur les matieres par exemple cela doit être commun aux deux sociétés, le logiciel comprenant une 40 de programmes il est plus facile de faire une "réplication" des modifications/insertion/suppression de la base "de référence" vers la base de la 2° société
[/CODE]

j'ai eu ce cas aussi, je voulais juste savoir quel était la raison d'une telle architecture . en plus c'est une application qu'il a repris ...

[cantador]

@Issam

pourquoi 4 bases de données ?

sinon vu de loin , je dirais qu'il faut en urgence centraliser tout ce ****** et tout mettre dans une seule base de données,
ou alors mettre un système de réplication .

houlà !
ça c'est impossible, car les tables sont très grosses et les données changent d'une base à l'autre..
un énorme travail qui alourdirait le fonctionnement de l'appli et il faudrait tout redévelopper

@SergioMaster
intéressant, mais j'aurai besoin d'infos complémentaires :
il faudrait pouvoir propager cette procédure sur les 4 bases en tenant compte que l'admin sera déjà connecté à l'une d'entre elles
et faire cette opération en mode transactionnel.

@escartefigue

ou mieux en faire une nouvelle dans une base spécifique, et remplacer les accès par requête aux 4 différentes tables, par l'appel à un service unique (ou plutôt un service lecture et un service MàJ), qui centralise les différentes requêtes.

c'est effectivement, la solution que je préconise, car elle présente l'avantage de :
- de réduire la taille des bases (en supprimant les users dans chacune d'elle)
- d'avoir une seule connexion à une table dans une base, plus facile donc à gérer
- d'avoir à redévelopper que la partie connexion de l'application

pour l'instant avantage à escartefique

cantador

[SergioMaster]

pour l'instant avantage à escartefique

c'est d'ailleurs pour cela que je l'ai

intéressant, mais j'aurai besoin d'infos complémentaires :
il faudrait pouvoir propager cette procédure sur les 4 bases en tenant compte que l'admin sera déjà connecté à l'une d'entre elles

dans mon cas il y a une base "référente" et l'admin c'est moi (ou un de mes programmes )
maintenant les triggers sont certainement applicable aux autres bases , ces dernières n'ayant besoin que de mettre à jour la table référente quoique je crains la boucle dans ce cas là

et faire cette opération en mode transactionnel.

euh, un trigger transactionnel non là AMHA il faut plutôt penser réplication

[Barbibulle]

dans mon cas il y a une base "référente" et l'admin c'est moi (ou un de mes programmes )
maintenant les triggers sont certainement applicable aux autres bases , ces dernières n'ayant besoin que de mettre à jour la table référente quoique je crains la boucle dans ce cas là

euh, un trigger transactionnel non là AMHA il faut plutôt penser réplication

Les trigeurs sont exécutés dans une transaction. Et le execute statement peut être exécuté dans la transaction courante (c'est par defaut le cas) ou bien dans une transaction séparée (dans ce cas elle est auto-commit).

Je pense que c'est donc tout à fait faisable il faut simplement comme l'a pressenti SergioMaster gérer les mises à jours en boucle (circulaire).

Base1 est mis a jour, le trigger met a jour base2 le trigger de base2 met a jour base1 qui abouti à un deadlock de la transaction...

Pour ce faire il suffit de créer un utilisateur qui ne sera utiliser que pour la réplication....
exemple le user GESTIONUSER mot de passe 12345

le trigger dans la base 1 serait du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SET TERM ^ ;
CREATE TRIGGER UTILISATEURS_AUI0 FOR UTILISATEURS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
declare variable STMT varchar(250);
declare variable BDD varchar(100);
begin
  if (USER<>'GESTIONUSER') then -- propager dans les autres bases
  begin
    BDD = 'localhost:base2';
    STMT = 'UPDATE OR INSERT INTO UTILISATEURS(ID,NOM) VALUES (?,?)';
    EXECUTE STATEMENT (STMT) (NEW.ID, NEW.NOM)
      ON EXTERNAL DATA SOURCE :BDD as USER 'GESTIONUSER' password '12345';
  end
end 
^
SET TERM ; ^

Et dans base 2 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SET TERM ^ ;
CREATE TRIGGER UTILISATEURS_AUI0 FOR UTILISATEURS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
declare variable STMT varchar(250);
declare variable BDD varchar(100);
begin
  if (USER<>'GESTIONUSER') then -- propager dans les autres bases
  begin
    BDD = 'localhost:base1';
    STMT = 'UPDATE OR INSERT INTO UTILISATEURS(ID,NOM) VALUES (?,?)';
    EXECUTE STATEMENT (STMT) (NEW.ID, NEW.NOM)
      ON EXTERNAL DATA SOURCE :BDD as USER 'GESTIONUSER' password '12345';
  end
end 
^
SET TERM ; ^

Bien entendu il faut donner les droits à GESTIONUSER dans toutes les bases sur la table UTILISATEURS.
Et pour que le code du trigger soit identique sur toutes les bases on peut très bien imaginer que BDD ne soit pas en DUR dans le trigger mais récupérer dans un FOR SELECT d'une table interne contenant la liste les bases à mettre à jour....

[cantador]

@BarbiBulle

une transaction ou quatre transactions ?

[cantador]

et il y a une base par année..
ce qui veut dire que dans 3 ans, il y aura 7 bases à gérer

[Barbibulle]

Comme le j'ai écris précédemment :

Et pour que le code du trigger soit identique sur toutes les bases on peut très bien imaginer que BDD ne soit pas en DUR dans le trigger mais récupérer dans un FOR SELECT d'une table interne contenant la liste les bases à mettre à jour....

donc avec un trigger du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
SET TERM ^ ;
 
CREATE OR ALTER TRIGGER UTILISATEURS_AUI0 FOR UTILISATEURS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
declare variable STMT varchar(250);
declare variable CHAINE_CONNECTION varchar(300);
begin
  if (user<>'GESTIONUSER') then
  begin
    FOR
      select b.chaine_connection from bdd_archives b
        left join identite_archive i on i.annee=b.annee
        where i.annee is null
      INTO :CHAINE_CONNECTION
    DO
    BEGIN
      STMT = 'UPDATE OR insert INTO UTILISATEURS(ID,NOM) values (?,?)';
      execute STATEMENT (STMT) (NEW.id,new.nom) WITH common TRANSACTION
        ON EXTERNAL DATA SOURCE :CHAINE_CONNECTION as USER 'GESTIONUSER' password '12345';
    END
  end
end
^
 
SET TERM ; ^

Dans la table bdd_archives vous mettez la liste des bases à synchroniser
dans la table identite_archive il n'y a qu'un enregistrement qui contient l'année de la base de données (l'année à ne pas synchroniser car mis a jour en direct)

lorsque vous avez une nouvelle archive il suffit d'ajouter une ligne à la table bdd_archive de chacune des bases (pourquoi pas utiliser un autre trigger pour que ca le fasse tout seul...)

[cantador]

@BarbiBulle

merci pour ces propositions,
mais j'ai eu peur que cela soit un peu tortueux..
entre temps, j'ai pris mon courage à deux mains, et j'ai modifié
la phase de connexion avec une seule table dans une seule base de données.
c'était d'ailleurs très simple à coder..(1h30')
en introduisant un petit module de connexion à la nouvelle base au bon endroit et faisant le lien avec le reste..
propre nickel, et une seule transaction pour sécuriser.
et tout marche bien.
je n'ai plus qu'à faire fondre mes bases en retirant la table en trop.

et je peux aller me détendre

merci

cantador