Discussion :

[sbouvetJD]

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 :

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

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 :

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
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
    )

[sbouvetJD]

Bête que je suis :

Code :

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

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 ?

[sbouvetJD]

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

Code :

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

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...

[Sergejack]

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

Code :

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

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 ?

[SQLpro]

Autre façon :

Code :

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

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 +

[sbouvetJD]

Autre façon :

Code :

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

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

Merci de ces réponses !

[sbouvetJD]

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 :

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

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)

[Sergejack]

Quid de la partie dynamique par @lv_update ?

[sbouvetJD]

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 :

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

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 ...

[aieeeuuuuu]

Bonjour,

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...