Discussion :

[Eveanne]

Artemus,

Arf, tu as tout de même traité le cas n°5 c'était vraiment pas nécessaire, je ne le rencontre vraiment pas (il est vraiment trop tordu en plus. Si jamais j'étais tombée dessus, je serais allée voir les gars de la téléphonie pour leur dire que ça ne tourne vraiment pas rond chez eux )

Le numéro '11111' de botin_a1 n'est pas présent dans 'botin_a2', donc il est devenu obsolète.
Mais on sait qu'il est obsolète car un nouveau numéro '33333' présent dans botin_a2 n'est pas présent dans botin_a1.

La finalité est la même, mais on sait que '11111' est obsolète parce qu'on ne le retrouve pas dans "botin_a2".
En revanche, on retrouve bien '22222'. Et "33333" est donc un numéro manquant.
Le résultat final pour ce cas correspond bien à ce qui est attendu

Je suis en train d'adapter ta solution à mes tables, je reviendrai donner des nouvelles un peu plus tard

[Eveanne]

Bon, alors, je suis actuellement en train d'essayer d'exécuter la requête qui permet de remplir botin_temp...
Mais ça prend tellement de temps à s'exécuter, je me demande si elle s'exécute toujours...

EDIT : je pense que PhpMyaAdmin n'apprécie pas trop ma requête. Ca tourne toujours (visiblement), mais toujours pas de message d'erreur...
EDIT2 : Avec des index, ça fonctionne tout de suite mieux (à force d'avoir supprimé/recréé mes tables...)

Bon, je passe à la suite !

EDIT3 : bon, alors, pour une raison que j'ignore, je récupère tout de même + de 12 000 lignes dans mon équivalent de botin_final, donc... voila.
Je ne sais pas pourquoi. Ca voudrait dire que 12 000 personnes ont des faux numéros...? (j'espère pas, ça serait une catastrophe)

Faudra que je compare les numéros de l'AD (Annuaire 1), de l'annuaire téléphonique (Annuaire 2) et du botin_final...

[Artemus24]

Salut EveAnne.

La requête est fort compliqué et il faudrait ajouter des index pour la rendre plus performante.
C'est le fait que tes tables ne sont pas normalisées qui rend ton problème compliqué, mais aussi long à l'exécution.

Arf, tu as tout de même traité le cas n°5 c'était vraiment pas nécessaire ...

Le cas n°5 n'est qu'une conséquence possible de la façon dont les lignes peuvent se présenter dans un table.
Je ne l'ai pas traité comme un cas particulier, comme celui du cas n°7.
Si je l'ai indiqué, c'est juste pour montrer ce qui se passe et que au final tu auras toujours au maximum trois numéros de téléphone.
Cela signifie que s'il ne se présente pas dans tes tables alors il ne sera pas traité.

Autre point que je n'ai pas souligné, les numéros seront toujours triés du plus petit au plus grand.

Mais ça prend tellement de temps à s'exécuter, je me demande si elle s'exécute toujours...

Si la requête ne se plante pas alors elle fonctionne. Sans optimisation, elle risque de durée très très longtemps.

Avec des index, ça fonctionne tout de suite mieux (à force d'avoir supprimé/recréé mes tables...)

Vu que je n'ai qu'un jeu d'essai très réduit, il m'est impossible d'optimiser ta requête.
Utilise le 'explain' et quelques index afin de savoir ce dont la requête à besoin pour s'exécuter un peu plus rapidement.
Mais son extrême lenteur est normale, à cause de la quatrième partie que j'ai rajouté, celle qui sert à traiter le cas n°7.

J'espère que je ne me suis pas planté dans le résultat à produire. En tout cas, sur le jeu d'essai, cela fonctionne.

Je ne sais pas pourquoi. Ça voudrait dire que 12 000 personnes ont des faux numéros...? (j'espère pas, ça serait une catastrophe)

Sinon, comment passes-tu de mes colonnes à NULL pour mon exemple, à tes colonnes à vide pour tes tables ?
Je pense que ton problème vient du fait que NULL ne fonctionne pas comme vide.
Vide est une valeur et se traite comme une valeur.
Dans le type 'char', il est stocké à blanc et retourne selon le paralétrage de MySql, soit vide ou soit blanc, sur toute la longueur de la colonne.
Dans le type 'varchar', comme la colonne est de longueur variable, c'est vraiement un vide, c'est-à-dire une longueur = zéro.
NULL représente rien du tout et n'est donc pas une valeur. Au contraire, c'est une absence de valeur.
La seule façon de tester 'val' à 'null', c'est de faire 'val is null' ou bien 'val is not null'.
Dans les autres expressions, cela retourne toujours faux, comme par exemple 'val = null', ou encore 'val in (null)'.

Par exemple, si tu mets "where tel1 in (select tel2 from ...)".
Si tu as tel1 = null et tel2 = null, le résultat sera faux, tandis qu'avec vide, cela sera vrai.

Par simplicité, dans mon exemple, j'ai fait en sorte de n'avoir que des NULL.
Il faudra soit normaliser tes tables, c'est-à-dire remplacer le vide par NULL, ou bien alourdir la requête en tenant compte du vide.

Il est fréquent dans des tables de confondre la gestion des NULL avec celle des vides. C'est souvent un point mal compris !

Faudra que je compare les numéros de l'AD (Annuaire 1), de l'annuaire téléphonique (Annuaire 2) et du botin_final...

Alors bon courage, car tous les cas de figures ne sont pas forcément identiques.

@+

[Artemus24]

Salur EveAnne.

Comme je suppose que tu as des problèmes avec les vides, voici une version qui remplace le 'NULL' par le vide.
De plus, j'ai remplacé les 'char' par des 'varchar'.

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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE IF NOT EXISTS `base`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `botin_1`
--------------
 
--------------
CREATE TABLE `botin_1` (
        `mail` varCHAR(30)  NOT NULL,
        `tel1` varCHAR(10)      NULL DEFAULT '',
        `tel2` varCHAR(10)      NULL DEFAULT '',
        primary key (`mail`)
)       ENGINE=InnoDB
        DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
        ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `botin_1` (`mail`,`tel1`,`tel2`) values
  ('AAAAA',  '11111', '22222'),
  ('CCCCC',  DEFAULT, DEFAULT),
  ('DDDDD',  DEFAULT, DEFAULT),
  ('EEEEE',  DEFAULT, DEFAULT),
  ('FFFFF',  '11111', '22222'),
  ('GGGGG',  '11111', '22222'),
  ('ZZZZZ',  '11111', DEFAULT),
  ('HHHHH',  '11111', '22222'),
  ('IIIII',  '11111', DEFAULT),
  ('JJJJJ',  DEFAULT, DEFAULT),
  ('KKKKK',  '11111', DEFAULT)
--------------
 
--------------
select * from botin_1
--------------
 
+-------+-------+-------+
| mail  | tel1  | tel2  |
+-------+-------+-------+
| AAAAA | 11111 | 22222 |
| CCCCC |       |       |
| DDDDD |       |       |
| EEEEE |       |       |
| FFFFF | 11111 | 22222 |
| GGGGG | 11111 | 22222 |
| HHHHH | 11111 | 22222 |
| IIIII | 11111 |       |
| JJJJJ |       |       |
| KKKKK | 11111 |       |
| ZZZZZ | 11111 |       |
+-------+-------+-------+
--------------
DROP TABLE IF EXISTS `botin_2`
--------------
 
--------------
CREATE TABLE `botin_2` (
        `id`    INT UNSIGNED  NOT NULL AUTO_INCREMENT,
        `mail`  varCHAR(30)  NOT NULL,
        `tel1`  varCHAR(10)      NULL DEFAULT '',
        `tel2`  varCHAR(10)      NULL DEFAULT '',
        `tel3`  varCHAR(10)      NULL DEFAULT '',
        primary key (`id`,`mail`),
        UNIQUE INDEX (`id`)
)       ENGINE=InnoDB
        DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
        ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `botin_2` (`mail`,`tel1`,`tel2`,`tel3`) values
  ('BBBBB', '11111', default, default),
  ('CCCCC', '11111', '22222', '33333'),
  ('DDDDD', '11111', default, default),
  ('DDDDD', '22222', default, default),
  ('DDDDD', '33333', default, default),
  ('EEEEE', '11111', default, '22222'),
  ('EEEEE', '33333', default, default),
  ('EEEEE', '44444', '55555', default),
  ('FFFFF', '11111', '22222', default),
  ('GGGGG', '22222', '33333', default),
  ('ZZZZZ', '22222', default, default),
  ('HHHHH', '22222', '11111', default),
  ('IIIII', default, '11111', default),
  ('JJJJJ', default, default, default),
  ('JJJJJ', default, default, default),
  ('JJJJJ', default, default, default),
  ('JJJJJ', default, default, default),
  ('JJJJJ', default, default, default),
  ('JJJJJ', default, default, '11111'),
  ('KKKKK', default, default, default),
  ('KKKKK', default, default, default),
  ('KKKKK', default, default, default),
  ('KKKKK', default, default, default),
  ('KKKKK', default, default, '11111')
--------------
 
--------------
select * from botin_2
--------------
 
+----+-------+-------+-------+-------+
| id | mail  | tel1  | tel2  | tel3  |
+----+-------+-------+-------+-------+
|  1 | BBBBB | 11111 |       |       |
|  2 | CCCCC | 11111 | 22222 | 33333 |
|  3 | DDDDD | 11111 |       |       |
|  4 | DDDDD | 22222 |       |       |
|  5 | DDDDD | 33333 |       |       |
|  6 | EEEEE | 11111 |       | 22222 |
|  7 | EEEEE | 33333 |       |       |
|  8 | EEEEE | 44444 | 55555 |       |
|  9 | FFFFF | 11111 | 22222 |       |
| 10 | GGGGG | 22222 | 33333 |       |
| 11 | ZZZZZ | 22222 |       |       |
| 12 | HHHHH | 22222 | 11111 |       |
| 13 | IIIII |       | 11111 |       |
| 14 | JJJJJ |       |       |       |
| 15 | JJJJJ |       |       |       |
| 16 | JJJJJ |       |       |       |
| 17 | JJJJJ |       |       |       |
| 18 | JJJJJ |       |       |       |
| 19 | JJJJJ |       |       | 11111 |
| 20 | KKKKK |       |       |       |
| 21 | KKKKK |       |       |       |
| 22 | KKKKK |       |       |       |
| 23 | KKKKK |       |       |       |
| 24 | KKKKK |       |       | 11111 |
+----+-------+-------+-------+-------+
--------------
DROP TABLE IF EXISTS `botin_temp`
--------------
 
--------------
CREATE TABLE `botin_temp` (
  `mail`  char(30)     NOT NULL,
  `tel`   char(10)         NULL DEFAULT '',
  primary key (`mail`,`tel`)
)       ENGINE=InnoDB
        DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
        ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `botin_temp` (`mail`,`tel`)
                              select mail, tel1 as tel from botin_2 as t2 where                                             tel1 not like ''
      and       exists (      select mail              from botin_1 as t1 where t2.mail = t1.mail)
      and (tel1 not in (      select       tel1 as tel from botin_1 as t1 where t2.mail = t1.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t1 where t2.mail = t1.mail and tel2 not like '')
      or ((tel1 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel1 not like '')
      or  (tel2 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel2 not like '')
      or  (tel3 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel3 not like '')))
 
union                         select mail, tel2 as tel from botin_2 as t2 where                                             tel2 not like ''
      and       exists (      select mail              from botin_1 as t1 where t2.mail = t1.mail)
      and (tel2 not in (      select       tel1 as tel from botin_1 as t1 where t2.mail = t1.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t1 where t2.mail = t1.mail and tel2 not like '')
      or ((tel1 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel1 not like '')
      or  (tel2 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel2 not like '')
      or  (tel3 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel3 not like '')))
 
union                         select mail, tel3 as tel from botin_2 as t2 where                                             tel3 not like ''
      and       exists (      select mail              from botin_1 as t1 where t2.mail = t1.mail)
      and (tel3 not in (      select       tel1 as tel from botin_1 as t1 where t2.mail = t1.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t1 where t2.mail = t1.mail and tel2 not like '')
      or ((tel1 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel1 not like '')
      or  (tel2 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel2 not like '')
      or  (tel3 not in (      select       tel1 as tel from botin_1 as t3 where t2.mail = t3.mail and tel1 not like ''
                        union select       tel2 as tel from botin_1 as t3 where t2.mail = t3.mail and tel2 not like '') and tel3 not like '')))
--------------
 
--------------
select * from botin_temp
--------------
 
+-------+-------+
| mail  | tel   |
+-------+-------+
| CCCCC | 11111 |
| CCCCC | 22222 |
| CCCCC | 33333 |
| DDDDD | 11111 |
| DDDDD | 22222 |
| DDDDD | 33333 |
| EEEEE | 11111 |
| EEEEE | 22222 |
| EEEEE | 33333 |
| EEEEE | 44444 |
| EEEEE | 55555 |
| GGGGG | 22222 |
| GGGGG | 33333 |
| JJJJJ | 11111 |
| ZZZZZ | 22222 |
+-------+-------+
--------------
DROP TABLE IF EXISTS `botin_final`
--------------
 
--------------
CREATE TABLE `botin_final` (
        `mail`  CHAR(30)  NOT NULL,
        `tel1`  CHAR(10)      NULL DEFAULT '',
        `tel2`  CHAR(10)      NULL DEFAULT '',
        `tel3`  CHAR(10)      NULL DEFAULT ''
)       ENGINE=InnoDB
        DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
        ROW_FORMAT=COMPRESSED
--------------
 
--------------
DROP PROCEDURE IF EXISTS `remplir`
--------------
 
--------------
CREATE PROCEDURE `remplir`()
BEGIN
DECLARE _rupt   CHAR(30);
 
DECLARE _clef   CHAR(30);
DECLARE _tel    CHAR(10);
 
DECLARE _mail   CHAR(30);
DECLARE _tel1   CHAR(10) DEFAULT '';
DECLARE _tel2   CHAR(10) DEFAULT '';
DECLARE _tel3   CHAR(10) DEFAULT '';
 
DECLARE _fin INTEGER DEFAULT 1;
DECLARE _tab CURSOR FOR SELECT mail, tel from botin_temp order by mail, tel;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET _fin = 0;
 
OPEN _tab;
FETCH _tab INTO _clef, _tel;
SET _rupt = _clef;
 
WHILE (_fin)
DO
  if (_rupt = _clef) then
    SET _mail = _clef;
 
    if     (_tel1 = '') then SET _tel1 = _tel;
    elseif (_tel2 = '') then SET _tel2 = _tel;
    elseif (_tel3 = '') then SET _tel3 = _tel;
    end if;
  else
    insert into `botin_final` (`mail`, `tel1`, `tel2`, `tel3`) values (_mail, _tel1, _tel2, _tel3);
 
    SET _mail = _clef;
    SET _tel1 = _tel;
    SET _tel2 = '';
    SET _tel3 = '';
    SET _rupt = _clef;
  end if;
 
  FETCH _tab INTO _clef, _tel;
END WHILE;
 
insert into `botin_final` (`mail`, `tel1`, `tel2`, `tel3`) values (_mail, _tel1, _tel2, _tel3);
 
CLOSE _tab;
END
--------------
 
--------------
COMMIT
--------------
 
--------------
call remplir()
--------------
 
--------------
select * from botin_final
--------------
 
+-------+-------+-------+-------+
| mail  | tel1  | tel2  | tel3  |
+-------+-------+-------+-------+
| CCCCC | 11111 | 22222 | 33333 |
| DDDDD | 11111 | 22222 | 33333 |
| EEEEE | 11111 | 22222 | 33333 |
| GGGGG | 22222 | 33333 |       |
| JJJJJ | 11111 |       |       |
| ZZZZZ | 22222 |       |       |
+-------+-------+-------+-------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

Et on obtient le même résultat. Cela va de soi !

@+

[Eveanne]

Salut Artemus,

Pour les index, ils ont été ajoutés, et l'exécution de la requête se passe à merveille désormais .
La procédure stockée aussi est très rapide
Plus de soucis de ce côté là donc.

Autre point que je n'ai pas souligné, les numéros seront toujours triés du plus petit au plus grand.

Ha oui ?? C'est marrant, ça me fait un tri par mail chez moi... par ordre alphabétique... bon, de toute façon, cela n'a pas d'importance !

Pour les NULL/vide : à l'import des csv dans mes tables, les champs "vides" sont à NULL. J'ai mis un certain temps à comprendre que NULL et vide étaient deux choses différentes. Pour me "rassurer", je remplace mes champs NULL par des champs ' '. Bon, peut-être que je ne devrais pas, mais à ce moment-là, ça me perturbait de voir des NULL partout.
Du coup, pour tes requêtes, je les ai adaptées en fonction, et tous les "is not null" ont été remplacés par des " != '' ", pour que ça fonctionne.

J'ai fait une vérif (enfin DES vérifs, assez longues), comparé certains numéros de l'AD (Annuaire 1)/annuaire téléphonique (Annuaire 2) et de l'annuaire final, et... ça bloque toujours. Plus ou moins.
Ce qui me rassure, c'est que non, il n'y a pas 12 000 faux numéros dans l'AD (ouf).

La TRES bonne nouvelle, c'est que tous mes cas un peu bizarres semblent être gérés correctement. Ca, c'est super cool, et pour ça, un IMMENSE merci (encore !)
Le plus gros (et le plus chiant) me semble être fait. Ouf.

Le problème, c'est qu'encore une fois, je ne récupère pas juste les numéros pour lesquels il y a une modification/correction à faire, mais TOUS les numéros.
Peut-être ai-je fais une erreur quelque part (ce qui est possible après tout... même si ça serait étrange, parce que j'ai fait un exact copier/coller de tes requêtes, et j'ai juste modifié les noms des tables/champs) ?

En gros, j'ai toujours ça (par ex) :

Code :

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

1
2
3
4
5
6
7
8
+=====+======================++==============================++==============================+===============================+
|     |      Annuaire 1      ||          Annuaire 2          ||        Annuaire Final        |                               |
| Cas |------+-------+-------++------+-------+-------+-------++------+-------+-------+-------|          Commentaire          |
|     | MAIL | TEL 1 | TEL 2 || MAIL | TEL 1 | TEL 2 | TEL 3 || MAIL | TEL 1 | TEL 2 | TEL 3 |                               |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+
|  1  | AAAA | 11111 | ..... || AAAA | 11111 | ..... | ..... || AAAA | 11111 | ..... | ..... | Annuaire final                |
|     |      |       |       ||      |       |       |       ||      |       |       |       | devrait être vide             |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+

J'arrive pas trop à comprendre pourquoi dans ton jeu d'essai, tu récupères juste ce qu'il faut, et moi, je récupère TOUT (= 13 000 lignes).
Je pensais pouvoir au moins présenter ça (après tout, le résultat que j'obtiens n'est pas faux), mais justement, on vient de me faire comprendre que ça n'allait pas
Bon.

Je craque

Je vois pas trop ce qu'on (enfin, ce que tu (parce que c'est toi qui as fait tout le boulot)) pourrait faire pour rendre le truc optimal.

Limite, je t'aurais bien donné une vue sur les vraies données de mes bases, mais :

1/ t'as déjà beaucoup fait, et je ne veux pas TROP abuser
2/ clairement, je ne peux rien poster ici, puisque je manipule des adresses mail, numéros de téléphone de mon travail...

J'essaye de réfléchir logiquement, mais bon...
C'est la procédure stockée qui permet de remplir l'annuaire final.
Donc je présume que c'est dans la procédure stockée que le problème se trouve...?

[Artemus24]

Salut EveAnne.

Autre point que je n'ai pas souligné, les numéros seront toujours triés du plus petit au plus grand.

Ha oui ?? C'est marrant, ça me fait un tri par mail chez moi... par ordre alphabétique... bon, de toute façon, cela n'a pas d'importance !

Je parle de la table "botin_temp" ! Pour un 'mail' donné, tous les numéros de téléphone sont triés du plus petit au plus grand.
De même, le 'mail' est aussi tri du plus petit au plus grand. Et il ne faut pas dire que cela n'a pas d'importance !!!
Car la rupture de séquence que je fais dans la procédure stockée ne peut fonctionner correctement que si la table 'botin_temp' est trié correctement.

Normalement, tu ne dois pas avoir de numéro de téléphone à vide ou à 'NULL' dans cette table.
Et dans la table 'botin_final', tu as au maximum que trois numéros de téléphone de renseignés.

J'ai mis un certain temps à comprendre que NULL et vide étaient deux choses différentes.

Un 'NULL', c'est une absence de valeur, tandis qu'un vide, c'est une valeur non renseignée.
Il y a bien une subtilité entre ces deux notions et ils ne fonctionnent pas de la même façon.

Un 'NULL' se teste toujours par un "is NULL" ou un 'is NOT NULL'.
Un vide se teste par un "like ''" ou par un "not like ''", c'est-à-dire par une chaîne de caractères vide.

Du coup, pour tes requêtes, je les ai adaptées en fonction, et tous les "is not null" ont été remplacés par des " != '' ", pour que ça fonctionne.

J'ai déjà eu des surprises en testant par "= ''" ou par un "<> ''" ou même par un "!= ''". C'est pourquoi je n'utilise pas cette forme d'écriture.
C'est bien un vide et non un blanc qu'il faut mettre entre les deux apostrophes (ou guillemet).

Dans mon dernier message, je t'ai donné un exemple où je teste le vide à la place du 'NULL'. J'espère que tu en es inspirée.

En gros, j'ai toujours ça (par ex) :

Es-tu certaine d'avoir toujours dans toutes tes tables des chaines vides, et pas une chaîne contenant un ou plusieurs blancs ?
Le fonctionnement du vide peut être différent si tu utilises un 'CHAR' ou un 'VARCHAR'.
Sur un 'char', vide ou une chaîne avec des blancs, c'est pareil : c'est vide.
Sur un 'varchar', un vide, c'est bien une chaîne vide. Mais une chaîne avec des blancs, ce n'est pas du vide. Ici, la distinction existe.
Assure-toi en faisant un test que c'est bien un vide qui est stocké et non autre chose !

Donc je présume que c'est dans la procédure stockée que le problème se trouve...?

Non, la procédure stockée n'est pas en cause. Le problème vient de ce qui est présent dans la table 'botin_temp'.
Si tu as le numéro '11111' pour le mail 'AAAA' dans le 'botin-final', c'est que tu as autre chose que du vide dans tes tables pour ce 'mail'.
En fait, il a récupéré tout ce qui existe dans 'botin_2' pour ce mail. Ceci est le cas n°7.

C'est pourquoi, avec un 'NULL', on voit tout de suite ce qu'il y a dans la colonne.
Visuellement, je ne sais pas distinguer une chaîne vide, d'une chaîne contenant un ou plusieurs blancs.
Sauf en faisant dans un select, ceci : "concat('-->',chaine,'<--')" ou encore en testant la longueur de ta chaine : "CHAR_LENGTH(chaine)".

@+

[Eveanne]

Je parle de la table "botin_temp" ! Pour un 'mail' donné, tous les numéros de téléphone sont triés du plus petit au plus grand.
De même, le 'mail' est aussi tri du plus petit au plus grand. Et il ne faut pas dire que cela n'a pas d'importance !!!
Car la rupture de séquence que je fais dans la procédure stockée ne peut fonctionner correctement que si la table 'botin_temp' est trié correctement.

Ha, d'accord ! J'avais mal compris, pardon !
Oui, c'est exact alors.
Et effectivement, je n'ai aucun numéro de téléphone vides/NULL dans cette table.

Bon, vu tout ce que tu me dis sur le NULL/vide, je vais refaire mes tests en laissant les valeurs à NULL.
Et donc réadapter tes requêtes. Et les miennes par la même occasion.

[Eveanne]

Petite question comme ça en passant, juste pour être sûre : on est d'accord que la requête qui remplit botin_temp permet de lister TOUS les numéros pour chaque adresse mail présente de Annuaire 2 ?

EDIT : je réponds à ma propre question. La réponse est donc OUI. Comme j'avais bien compris, donc.
Bon, bon, bon.

J'ai modifié mes "vides" par des NULL, et là, le résultat n'est pas probant du tout du tout du tout...

D'un côté, quand je laisse mes cases vides (quand je ne les remplace pas par NULL), mon équivalent de botin_temp récupère TOUS les numéros de téléphone pour toutes les adresses mails présentes dans Annuaire 2, ce qui est le but recherché.
Le souci se situe après, puisque qu'au lieu de n'avoir que les numéros à corriger dans l'annuaire final, j'ai... TOUT (environ 13 000 lignes, en fonction du contenu des fichiers csv importés)

Or, quand je remplace mes "vides" par des NULL, dans le botin_temp, je ne récupère pas du tout l'intégralité des numéros. J'en suis même très loin. Ce qui donne un résultat totalement faux dans l'annuaire final.

A partir de ces maigres explications, tu penses que c'est la gestion de mes cases vides/NULL qui pose problème ? Le truc, c'est qu'avec des NULL, visiblement, ça ne résout rien, donc là, j'arrive vraiment pas à voir ce qui ne va toujours pas...
Tous mes champs avec numéros de téléphone et mail sont en varchar déjà...

[Artemus24]

Salut EveAnne.

Et effectivement, je n'ai aucun numéro de téléphone vides/NULL dans cette table.

Est-ce que tu parles bien de la table 'botin_temp' ? Si le réponse est OUI alors c'est tout à fait normal.
Car on ne doit récupérer que des numéros de téléphone en provenance de 'botin_2' et uniquement des numéros, pas de vide et pas de null.

Si la réponse est NON alors tu as un problème avec tes vides.
Un vide, ce n'est pas une chaîne contenant un ou plusieurs blancs dans le type 'varchar'.
Un vide, c'est un 'varchar' de longueur zéro !

Ensuite, il y a le formatage de tes numéros de téléphone.
Par exemple : '1234567890' ou '12 34 56 78 90' ou encore '1234567890 '.
Il s'agit pourtant du même numéro de téléphone mais les chaînes de caractères sont toutes différentes.
Le problème vient de l'insertion de un ou plusieurs blancs dans ces chaînes de caractères !

Bon, vu tout ce que tu me dis sur le NULL/vide, je vais refaire mes tests en laissant les valeurs à NULL.

Il ne s'agit pas de relancer le traitement mais de chercher la cause sur les exemples qui ne fonctionnent pas.

Vu que je n'ai pas accès à ton environnement, je vais devoir émettre des hypothèses pour comprendre la cause de ton problème.
Je pense que des blancs (ou autre chose) viennent perturber la comparaison des numéros de téléphone, ou des 'mail'.

Petite question comme ça en passant, juste pour être sûre : on est d'accord que la requête qui remplit botin_temp permet de lister TOUS les numéros pour chaque adresse mail présente de Annuaire 2 ?

Tu ne sais pas lire une requête MySql ?

Code :

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

1
2
3
4
5
select mail, tel1 as tel from botin_2
...
select mail, tel2 as tel from botin_2
...
select mail, tel3 as tel from botin_2...

signifie que j'extrais les 'mail' et les numéros de téléphone depuis la table 'botin_2'.
Je ne récupère aucun 'mail' ou numéros de téléphone de la table 'botin_1'. C'est ce que tu m'as demandé de faire !

Le souci se situe après, puisque qu'au lieu de n'avoir que les numéros à corriger dans l'annuaire final, j'ai... TOUT (environ 13 000 lignes, en fonction du contenu des fichiers csv importés)

Il y a peut être un problème au chargment de tes fichiers CSV dans tes tables MySql.
C'est à toi de faire les analyses pour comprendre les causes de tes problèmes. Je ne peux rien faire de plus, vu que je n'ai pas accès à ton environnement.

Or, quand je remplace mes "vides" par des NULL, dans le botin_temp, je ne récupère pas du tout l'intégralité des numéros.

J'avais cru comprendre que tu n'avais aucun vide ou null dans 'botin-temp' ????? Normalement, tu ne dois pas en avoir.

C'est dans 'botin_1' ou dans 'botin_2' que tu dois vérifier les vides ou les NULL et pas ailleurs.

Tous mes champs avec numéros de téléphone et mail sont en varchar

Les blancs qui sont en fin de tes chaînes des caractères sont conservés avec 'varchar' mais pas avec 'char'.
Cela peut perturber grandement les résultats.

Je te propose de tester la syntaxe des numéros et des 'mail'.

1) un numéro de téléphone est composé de dix chiffres. Pas un de plus, ni un de moins.

Code :

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

select tel1 from botin_1 where tel1 regexp '^[0-9]{10}$';

2) recherche des blancs.

Code :

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

select tel1 from botin_1 where tel1 regexp '[[:blank:]]';

3) tester une adresse mail.

Code :

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

select mail from botin_1 where mail regexp regexp '^[a-z0-9\.\-]+@[a-z0-9\.\-]{2,}\.[a-z]+$';

Si tu veux l'inverse de la condition, tu mets 'not regexp'.

N'y-a-t-il personne dans ton équipe ou dans ta boîte qui peut t'aider à résoudre ce genre de problème ?
Ce n'est pas insurmontable comme problème à résoudre, mais comme je l'ai dit précédemment, il faut au préalable avoir une base de données normalisée.
En principe, c'est le travail d'un DBA de garantir la normalisation et l'intégrité de tes données.

Je suppose que cela ne va pas du tout résoudre tes problèmes, le mieux serait de m'envoyer un extrait de tes deux tables 'botin_1' et 'botin_2.
Pas la totalité, mais juste disons une bonne centaine de lignes. Fais en sorte de m'envoyer les lignes qui pose des problèmes.
Tu fais un 'export' de ces tables, et tu m'envoies le tout à mon adresse email 'artemus@jcz.fr'.
A oui, la pièce jointe de l'email doit être de type '.txt' sinon cela risque de ne pas passer.

@+

[Eveanne]

Est-ce que tu parles bien de la table 'botin_temp' ? Si le réponse est OUI alors c'est tout à fait normal.

Oui, c'est bien de cette table là dont je parle. Donc pas de problème de ce coté là.

Ensuite, il y a le formatage de tes numéros de téléphone.
Par exemple : '1234567890' ou '12 34 56 78 90' ou encore '1234567890 '.
Il s'agit pourtant du même numéro de téléphone mais les chaînes de caractères sont toutes différentes.
Le problème vient de l'insertion de un ou plusieurs blancs dans ces chaînes de caractères !

Oui, et j'ai bien fait attention à ça.

A l'import du csv de l'AD, il y a des espaces dans les champs (+33 1 XX XX XX XX). Donc, je les retire avec un 'update... replace', ce qui fonctionne très bien, et j'ai des numéros au bon format dans mon Annuaire 1 (+331XXXXXXXX)
Dans mon Annuaire 2, les numéros sont déjà au bon format.

Pour le champ tel de Annuaire 1, à cause de ces espaces, j'ai dû le mettre en VARCHAR (17). Car avec une valeur plus petite, les numéros sont coupés...
Les champs tel de Annuaire 2, botin_temp et Annuaire_final sont en VARCHAR (12) (que je pourrais éventuellement mettre en CHAR (12), d'ailleurs).

Tu ne sais pas lire une requête MySql ?

Je ne récupère aucun 'mail' ou numéros de téléphone de la table 'botin_1'. C'est ce que tu m'as demandé de faire !

Si si, je sais lire, et j'avais bien lu l'explication que tu avais fait de cette requête...
Le truc c'est que, en voyant la différence de résultat (et c'est pas une petite différence) pour la même requête, pour une table avec des champs 'vides' et une table avec des champs 'NULL', j'ai commencé à douter, c'est tout...
Mais oui, c'était bien le résultat attendu, sinon.

Il y a peut être un problème au chargment de tes fichiers CSV dans tes tables MySql.

Là, ça serait difficile à régler comme souci...
J'ai eu des problèmes, au tout début, notamment au niveau d'encodage entre le csv de l'AD et celui de la table, mais tout ça a été réglé depuis longtemps. A priori, je n'ai plus à me préoccuper de problème à ce niveau là. Et puis, si jamais quelque chose bloquait à ce niveau, j'avoue que je ne saurais même pas quoi faire pour détecter les éventuels points bloquants...

Les blancs qui sont en fin de tes chaînes des caractères sont conservés avec 'varchar' mais pas avec 'char'.
Cela peut perturber grandement les résultats.

OK.
Donc revenons en justement à mon champ VARCHAR (17) de Annuaire 1.
Au départ, j'ai des numéros qui ressemblent à ça : '+33 1 XX XX XX XX'. Tout ça, ça fait bien 17 caractères.
Puis, je fais un update dessus, et ça devient ça : '+331XXXXXXXX'. Ce qui ne fait plus que 12 caractères.
Mais je suis en VARCHAR (17). Donc ça signifie qu'en réalité, j'ai ça : '+331XXXXXXXX ' (avec des blancs après le dernier X) ?

De ce fait : quand la comparaison se fait entre les numéros d'Annuaire 1 ('+331XXXXXXXX ') et ceux de botin_temp ('+331XXXXXXXX'), il dit "hey, c'est pas pareil, donc j'envoie dans Annuaire_final !" ?

Donc : il faudrait qu'après mon update qui supprime les espaces, je change le type en VARCHAR (12) par exemple, pour que les blancs qui subsistent avec un VARCHAR (17) disparaissent...

Est-ce que ma réflexion est logique ? Est-ce que ça se tient ? Et est-ce qu'il y a une chance qu'en effectuant cette modification... ça fonctionne enfin ?
J'ai envie d'y croire, mais je suis tellement désespérée que... j'y crois plus du tout.

Les personnes susceptibles de potentiellement m'aider ne sont pas présentes actuellement.
Je ne l'ai pas précisé (mais cela n'a pas un très grande importance de toute façon), mais je suis apprentie, donc ceci explique en partie pourquoi ma base est loin d'être parfaite (et aussi pourquoi je n'ai pas le même fil de réflexion que toi pour tenter de résoudre cette galère). Je ne suis pas une experte en BDD, ni en SQL, mais j'ai essayé de faire une BDD qui tienne la route, en fonction des fichiers que l'on m'a fourni...

[Eveanne]

Alors, je viens de me rendre compte de quelque chose.

Je vais d'abord énoncer les modifications que j'ai faites :

1/ J'ai modifié le type du champ tel de l'Annuaire 1 en VARCHAR (12) (après suppression des espaces entre les nombres)
2/ J'ai (re)mis les champs tel/tel2/etc à NULL quand ils sont 'vides' dans les deux tables.
3/ dans l'Annuaire 2, j'ai viré les lignes sans mail (de toute façon, ces lignes ne servent à rien, puisque le mail est vide, on ne peut les comparer à rien)

A partir de là, j'exécute la requête qui rempli botin_temp.
1ère constatation : je ne récupère pas TOUS les numéros de l'Annuaire 2. Je n'ai au total que 205 lignes.
J'explique un peu plus : selon ce que j'ai compris donc, la requête qui remplit botin_temp récupère TOUS les numéros pour chaque adresse mail. Tout, tout, tout, sans distinction, sans comparaison avec Annuaire 1.

Pour être plus claire, je pensais récupérer un truc comme ça :

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
+-------+-------+
| mail  | tel   |
+-------+-------+
| AAAAA | 11111 |
| AAAAA | 22222 |
| BBBBB | 11111 |
| CCCCC | 11111 |
| CCCCC | 22222 |
| CCCCC | 33333 |
| DDDDD | 11111 |
| DDDDD | 22222 |
| EEEEE | 11111 |
| FFFFF | 11111 |
| GGGGG | 11111 |
| GGGGG | 22222 |
| HHHHH | 11111 |
| JJJJJ | 11111 |
| JJJJJ | 22222 |
| etc   | ...   |
+-------+-------+

Jusqu'à Z imaginons.

Or, là, je n'ai que :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
+-------+-------+
| mail  | tel   |
+-------+-------+
| AAAAA | 11111 |
| CCCCC | 11111 |
| CCCCC | 22222 |
| CCCCC | 33333 |
| DDDDD | 11111 |
| DDDDD | 22222 |
| FFFFF | 11111 |
| JJJJJ | 11111 |
| etc   | ...   |
+-------+-------+

On voit notamment qu'il n'y a qu'un seul numéro de 'AAAAA' qui est récupéré, par exemple (pourquoi ? Je ne sais pas...)

Mais qu'importe, j'ai ensuite exécuté la procédure stockée.
Là, pouf, il ne me reste plus que 175 lignes.

Certains cas sont bien résolus.
En revanche, d'autre pas, et je ne comprends pas pourquoi.

Exemple :

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
+=====+======================++==============================++==============================+===============================+
|     |      Annuaire 1      ||          Annuaire 2          ||        Annuaire Final        |                               |
| Cas |------+-------+-------++------+-------+-------+-------++------+-------+-------+-------|          Commentaire          |
|     | MAIL | TEL 1 | TEL 2 || MAIL | TEL 1 | TEL 2 | TEL 3 || MAIL | TEL 1 | TEL 2 | TEL 3 |                               |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+
|  1  | AAAA | 11111 | ..... || AAAA | 22222 | 33333 | ..... || AAAA | 22222 | 33333 | ..... | le num 11111 doit être        |
|     |      |       |       || AAAA | 11111 |       |       ||      |       |       |       |  récupéré également           |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+
 
 
+=====+======================++==============================++==============================+===============================+
|     |      Annuaire 1      ||          Annuaire 2          ||        Annuaire Final        |                               |
| Cas |------+-------+-------++------+-------+-------+-------++------+-------+-------+-------|          Commentaire          |
|     | MAIL | TEL 1 | TEL 2 || MAIL | TEL 1 | TEL 2 | TEL 3 || MAIL | TEL 1 | TEL 2 | TEL 3 |                               |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+
|  1  | AAAA | 11111 | ..... || AAAA | 11111 |       | ..... || AAAA | 22222 |       | ..... | le num 11111 doit être        |
|     |      |       |       || AAAA | 22222 |       |       ||      |       |       |       |  récupéré également           |
+=====+======+=======+=======++======+=======+=======+=======++======+=======+=======+=======+===============================+

Du coup, ça me fait me prendre conscience que c'est probablement un cas dont je n'avais pas parlé...?
Mais le truc encore plus bizarre, c'est que, pour deux cas similaires, l'un va être résolu, et l'autre pas

Artemus, je veux bien t'envoyer mes tables. Le seul truc, c'est qu'envoyer un extrait avec les cas les plus "pertinents" à trier dans chacune des tables, sachant que j'ai plus de 60 000 lignes d'un côté, et plus 16 000 lignes de l'autre... ça va me faire faire un sacré tri.
Ce que je te propose, c'est de t'envoyer l'intégralité, et de faire une petite liste de cas OK et pas OK (dans mon environnement).