Discussion :

[ighost]

Bonjour à tous,

Je vous écris car j'ai une problématique sur les base de données Firebird.

J'ai créé un logiciel permmetant de faire le fusion de deux base données Firebird ayant la même structure, le problème se situe au niveau de l'update des clefs étrangères.

En effet je renumérote toutes les clefs primaires et donc les clef étrangères pour permettre ensuite une fusion sans douleur des deux bases.

J'ai actuellement un base de donnée comprenant deux tables récalcitrantes, en effet une table A contenant 20 000 enregistrement donc sa clef primaire impacte une table B contenant 800000 enregistrement.

Le temps de traitement est d'une 4 heures, même si je m'attendais à ce que ce genre d'opération ne soit pas rapide c'est.... trop long.

Je passe actuellement par le FbScript qui lance toutes les requêtes d'un coup pour ces deux bases, les requêtes sont des simples update sur des colonnes primary key pour la première donc avec une contrainte mais sans aucune contrainte pour la deuxième (la FK n'est pas créé comme une vrai FK toute les contraintes ont été retirées).

Je suis à cours d'idée pour optimiser tout cela.

Si quelqu'un peut me venir en aide merci d'avance .

[escartefigue]

bonjour,

Quel est le format de vos colonnes PK, s'agit il de valeurs calculées par le système (auto-incrément) ? je suppose que non

800 000 lignes c'est très peu pour une BDD, il serait préférable de (re)mettre une contrainte "ON UPDATE CASCADE" sur la table qui hérite de la FK, puis de faire uniquement les update coté PK, le SGBD se chargera tout seul de propager les valeurs.

Par contre, si les volumes étaient importants, d'autres solutions seraient à envisager

Pensez à faire une réorg et mettre à jour les stats après opération

[ighost]

la pk de la table A est un champs varchar et la pk de la table B est la concaténation de 4 champs dont 2 varchars.

Je ne peux malheureusement pas changer la structure de la base de données.

Je vais voir déjà si le onupdatecascade accélère le traitement.

[Artemus24]

Salut ighost.

Ce n'est pas une très bonne idée de mettre vos primary key dans le type varchar.
Il serait mieux de mettre char ou encore d'utiliser un incrément automatique, comme ci-après (pour la version 3.0.0 uniquement) :

Code :

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

id integer generated by default as identity not null primary key,

Voici un exemple de modification de la clef primaire de la table "mère" et de sa propagation dans la clef étrangère de la table "fille".

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;
 
-- ============
-- Table 'mere'
-- ============
 
create table mere
( id    char(06)   not null,
  lib   char(10)   not null,
  primary key (id)
);
 
-- ===========
-- Jeu d'essai
-- ===========
 
insert into mere (id, lib) values ('num125', 'un');
insert into mere (id, lib) values ('num373', 'deux');
insert into mere (id, lib) values ('num425', 'trois');
insert into mere (id, lib) values ('num777', 'quatre');
insert into mere (id, lib) values ('num939', 'cinq');
 
-- ==============
-- Vidage de mere
-- ==============
 
select * from mere;
 
ID     LIB
====== ==========
num125 un
num373 deux
num425 trois
num777 quatre
num939 cinq
 
 
commit;
 
-- =============
-- Table 'fille'
-- =============
 
create table fille
( id    smallint   generated by default as identity not null primary key,
  clef  char(06)   REFERENCES mere (id) ON DELETE CASCADE ON UPDATE CASCADE,
  val   char(10)   not null
);
 
-- ===========
-- Jeu d'essai
-- ===========
 
insert into fille (clef, val) values ('num125', 'one');
insert into fille (clef, val) values ('num373', 'two');
insert into fille (clef, val) values ('num425', 'three');
insert into fille (clef, val) values ('num777', 'four');
insert into fille (clef, val) values ('num939', 'five');
 
insert into fille (clef, val) values ('num125', 'eins');
insert into fille (clef, val) values ('num373', 'zwei');
insert into fille (clef, val) values ('num425', 'drei');
insert into fille (clef, val) values ('num777', 'vier');
insert into fille (clef, val) values ('num939', 'fünf');
 
insert into fille (clef, val) values ('num125', 'uno');
insert into fille (clef, val) values ('num373', 'duo');
insert into fille (clef, val) values ('num425', 'tre');
insert into fille (clef, val) values ('num777', 'quattro');
insert into fille (clef, val) values ('num939', 'cinque');
 
-- ===============
-- Vidage de fille
-- ===============
 
select * from fille;
 
     ID CLEF   VAL
======= ====== ==========
      1 num125 one
      2 num373 two
      3 num425 three
      4 num777 four
      5 num939 five
      6 num125 eins
      7 num373 zwei
      8 num425 drei
      9 num777 vier
     10 num939 fünf
     11 num125 uno
     12 num373 duo
     13 num425 tre
     14 num777 quattro
     15 num939 cinque
 
 
commit;
 
-- ==============
-- Initialisation
-- ==============
 
create sequence seq$rang;
 
-- ============================
-- Renumérotation Clef Primaire
-- ============================
 
update mere set id='Rang' || right('00' || gen_id(seq$rang, 1),2) order by id;
 
-- =================
-- Vidage des tables
-- =================
 
select *
from       mere   as m
inner join fille  as f
on f.clef = m.id;
 
ID     LIB             ID CLEF   VAL
====== ========== ======= ====== ==========
Rang01 un               1 Rang01 one
Rang01 un               6 Rang01 eins
Rang01 un              11 Rang01 uno
Rang02 deux             2 Rang02 two
Rang02 deux             7 Rang02 zwei
Rang02 deux            12 Rang02 duo
Rang03 trois            3 Rang03 three
Rang03 trois            8 Rang03 drei
Rang03 trois           13 Rang03 tre
Rang04 quatre           4 Rang04 four
Rang04 quatre           9 Rang04 vier
Rang04 quatre          14 Rang04 quattro
Rang05 cinq             5 Rang05 five
Rang05 cinq            10 Rang05 fünf
Rang05 cinq            15 Rang05 cinque
 
 
exit;
 
Appuyez sur une touche pour continuer...

@+

[SergioMaster]

Bonjour,
n'y aurait-il pas des triggers sur la table destination ?

[ighost]

Bonjour,

Alors malheureusement c'est une solution vendu et le traitement doit être fait sur des bases existantes déjà chez les clients donc pas de possibilité de modification...

Cependant je vous remercie mais je me suis rendu compte de mon erreur, je mettais à jour une FK à partir de la mauvaise PK... donc il ne trouvait jamais rien à updater, résultat il parcourais tous les enregistrements pour rien à chaque fois.

Bizarrement en mettant la bonne relation c'est instantanée.

[escartefigue]

Effectivement, encore une fois, 800 000 lignes c'est de la gnognotte pour une BDD, donc pas de raison si la construction est correcte, que le traitement soit long.
Cela dit,
- Créer des PK de type varchar et une hérésie
- Ne pas implémenter les contraintes d'intégrité est un très gros risque