UPDATE et JOINTURE ?

Version imprimable

Bonjour,

Je possède une table POPULATION contenant ~3M enr. avec des informations diverses des individus de la population (tranches d'âge, habitude d'achats, etc.)

J'ai dans cette table un champ me permettant de cibler mes populations en fonction de certains critères. Je génère en fonction des besoins de l'utilisateur un critère d'UPDATE de ce champ via une requête du type
Code:

1 2 3 UPDATE POPULATION SET CODECIBLE = <VALEURCODE> WHERE SEGMENT1 = <VALEURSEGMENT1> AND SEGMENT2 = <VALEURSEGMENT2>...
Je dois rajouter un critère de sélection spécifiant si l'individu a précédemment été contacté. Pour ce faire, je dois consulter les informations de tables CIBLE et ACTION spécifiant les périodes et actions de sollicitations menées auprès desdits individus.

ma table ACTION (~40K enr.) contient outre la PK (ID), des dates de ciblages (DD_DEB, DD_FIN) ;
ma table CIBLE (~36M enr.) contient outre la PK (ID), l'ID_ACTION et l'ID_INDIVIDU.

J'hésite entre deux syntaxe pour mon update :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 UPDATE POPULATION SET CODECIBLE = <VALEURCODE> WHERE EXISTS ( SELECT * FROM CIBLE INNER JOIN ACTION ON CIBLE.ID_ACTION = ACTION.ID WHERE DD_DEB BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01') AND DD_FIN BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01') AND POPULATION.ID_INDIVIDU = CIBLE.ID_INDIVIDU ) UPDATE POPULATION SET CODECIBLE = <VALEURCODE> WHERE 1 >= ( SELECT COUNT(*) FROM CIBLE INNER JOIN ACTION ON CIBLE.ID_ACTION = ACTION.ID WHERE DD_DEB BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01') AND DD_FIN BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01') AND POPULATION.ID_INDIVIDU = CIBLE.ID_INDIVIDU )

Bête que je suis :

Code:

1
2
3
4
5
6
UPDATE POPULATION
SET CODECIBLE = <VALEURCODE>
FROM CIBLE INNER JOIN ACTION ON CIBLE.ID_ACTION = ACTION.ID 
WHERE DD_DEB BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01')
    AND DD_FIN BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01')
    AND POPULATION.ID_INDIVIDU = CIBLE.ID_INDIVIDU

Validez-vous ?

...Suis-je bête bis, je ne peux utiliser cette option car j'utilise une procédure du type :
Code:

1 2 3 4 5 6 7 8 9 10 11 CREATE PROCEDURE dbo.sp_update_population @lv_update VARCHAR(8000), @lv_where VARCHAR(8000) AS BEGIN DECLARE @lv_query nVARCHAR(4000) SET @ls_query = 'UPDATE POPULATION SET ' + @lv_update + ' WHERE ' + @lv_where EXEC sp_executesql @query = @lv_query END
Cette procédure est appelée depuis mon applicatif de segmentation.

Donc à moins d'inclure mon "FROM..." dans la clause @lv_update...

21/03/2013, 11h31
aieeeuuuuu

Bonjour,

Citation:

J'hésite entre deux syntaxe pour mon update :

A priori la première sera plus efficace : Le moteur "s’arrêtera" de chercher dès qu'il trouvera UNE ligne qui correspond à votre critère, dans la deuxième, le moteur cherchera TOUTES les lignes qui correspondent à votre critère (pour les compter).

Plus globalement, pour comparer les performances de deux requêtes, vous pouvez les placer l'une en dessous de l'autre et afficher leur plan d’exécution : chaque plan indiquera un cout, avec un pourcentage pour ce cout par rapport au lot...

Citation:
Envoyé par sbouvetJD
...Suis-je bête bis, je ne peux utiliser cette option car j'utilise une procédure du type :
Code:

1 2 3 4 5 6 7 8 9 10 11 CREATE PROCEDURE dbo.sp_update_population @lv_update VARCHAR(8000), @lv_where VARCHAR(8000) AS BEGIN DECLARE @lv_query nVARCHAR(4000) SET @ls_query = 'UPDATE POPULATION SET ' + @lv_update + ' WHERE ' + @lv_where EXEC sp_executesql @query = @lv_query END
Cette procédure est appelée depuis mon applicatif de segmentation.

Donc à moins d'inclure mon "FROM..." dans la clause @lv_update...
Pourquoi un query dynamique ?

Pourquoi pas une procédure avec tous les paramètres nécessaires ?

Autre façon :

Code:

1
2
3
4
5
6
7
8
9
UPDATE P
SET    CODECIBLE = '<VALEURCODE>'
FROM   POPULATION AS P
       INNER JOIN CIBLE  AS C 
             ON P.ID_INDIVIDU = C.ID_INDIVIDU
       INNER JOIN ACTION AS A 
             ON C.ID_ACTION = A.ID 
WHERE  DD_DEB BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01')
  AND  DD_FIN BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01');

Évaluez les différents plans de requête !

A +

Citation:

Envoyé par Sergejack

Pourquoi un query dynamique ?

Pourquoi pas une procédure avec tous les paramètres nécessaires ?

Car les paramètres sont saisis dynamiquement dans l'applicatif et la plupart sont optionnels ou à valeurs multiples

exemple :
SEG0 IN (1) AND SEG1 IN (2,1) AND SEG4 IN (4,2,1) AND SEG26 IN ('O9','OR') AND SEG16 IN ('FR')
-> Clients qui ont acheté dans nos magasins, durant les 24 derniers mois et qui font en moyenne un achat par an, majoritairement de l'or et originaires de France

Je pensais éventuellement populer une table de paramètres et opérer par jointure du type
Code:

1 2 3 4 5 6 UPDATE POPULATION SET CODECIBLE = VALEURCODE FROM PARAMETRES_SEGMENTATION WHERE (POPULATION.SEG0 = PARAMETRES_SEGMENTATION.SEG0 OR PARAMETRES_SEGMENTATION.SEG0 IS NULL) AND POPULATION.SEG1 = PARAMETRES_SEGMENTATION.SEG1 OR PARAMETRES_SEGMENTATION.SEG1 IS NULL) ...
Avec une table PARAMETRES_SEGMENTATION qui contiendrait donc une ligne par valeur possible des paramètres et une colonne par paramètre existant ?

(Mais du coup là on parle de refonte profonde du système, ce qui ne me paraît pas improbable si la pertinence et la performance sont au rendez-vous)

22/03/2013, 11h36
Sergejack

Quid de la partie dynamique par @lv_update ?

Citation:
Envoyé par SQLpro
Autre façon :
Code:

1 2 3 4 5 6 7 8 9 UPDATE P SET CODECIBLE = '<VALEURCODE>' FROM POPULATION AS P INNER JOIN CIBLE AS C ON P.ID_INDIVIDU = C.ID_INDIVIDU INNER JOIN ACTION AS A ON C.ID_ACTION = A.ID WHERE DD_DEB BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01') AND DD_FIN BETWEEN '2010-01-01' AND DATEADD(mi, 1439, '2010-02-01');
Évaluez les différents plans de requête !

A +
Comme dirait l'autre, "y a pas photo"
Si je mets en parallèle la version "EXISTS" et cette version j'obtiens :
"Query 1 : Query cost (relative to the batch) : 99.84%" (EXISTS)
"Qyery 2 : Query cost (relative to the batch) : 0.16%" (INNER JOIN)

Bon, je m'en doutais un peu :P

Merci de ces réponses !

22/03/2013, 11h55
sbouvetJD
Citation:

Envoyé par Sergejack

Quid de la partie dynamique par @lv_update ?

La construction du CODECIBLE est conditionnée par l'applicatif en fonction du numéro de la cible à générer (l'application permet de générer 5 cibles en série).
On aurait pu, au lieu de passer le @lv_update en paramètre (d'ailleurs je pense modifier cette partie), passer le @ci_cible et mettre du coup en "dur"
Code:

1 2 3 UPDATE POPULATION SET CODECIBLE = CASE WHEN FC_EXCLUSION = 'O' THEN '9' ELSE '0' END + CASE FC_ANNULE WHEN 'N' THEN '9' ELSE '0' END + RIGHT('0' + CONVERT(CHAR(2), @ci_cible), 2) WHERE ...