Toujours des problèmes avec MERGE

**Lyche** · 05/08/2014, 15h45

Je ne parlais pas de plus hein

Juste une petite note d'une ligne avant le merge pour expliquer le principe d'encapsulation et zou!

Et oui, il est clair qu'à moins d'être particulièrement sale dans ses déclarations de variable, ce n'est pas réellement compliqué à comprendre comme code

**Kropernic** · 05/08/2014, 15h48

Envoyé par Lyche

Je ne parlais pas de plus hein

Juste une petite note d'une ligne avant le merge pour expliquer le principe d'encapsulation et zou!

Et oui, il est clair qu'à moins d'être particulièrement sale dans ses déclarations de variable, ce n'est pas réellement compliqué à comprendre comme code

On est bien d'accord. Mais vu que mes collègues ne se tiennent pas au courant des avancées "technologiques", aucune chance qu'il sache comment fonctionne l'instruction merge.

Voici à quoi ressemble un bout de la procédure stockée sur laquelle je bosse actuellement. Perso, ça me semble assez clair. Si mon collègue direct doit aller dedans, je suis certain qu'il va patauger et que, s'il faut vraiment corriger un truc, réécrira le code avec des insert/update/delete.

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
    --MAJ DES GROUPES DE SAISONS
    DECLARE @INSERTED TABLE (
        SOURCE_ID INT,
        TARGET_ID INT);
 
    INSERT INTO @INSERTED
    SELECT SOURCE_ID, TARGET_ID    
    FROM    (
            --MERGING DES GROUPES DE SAISONS
            MERGE    S_PROMO.T_SEASON_GROUP_SGP AS TARGET
            USING    (SELECT DISTINCT LS.SGP_ID, LS.PEO_VALUE, LS.ISNEW, PEO.PEO_ID
                    FROM @LIST_SEASONS LS 
                            INNER JOIN S_PROMO.T_PERCENTAGE_OWN_PEO PEO
                                ON    PEO.DTO_ID = @DTO_ID
                                AND PEO.PEO_PERCENTAGE = LS.PEO_VALUE) AS SOURCE (SGP_ID, PEO_VALUE, ISNEW, PEO_ID)
                ON    (TARGET.SGP_ID = SOURCE.SGP_ID AND SOURCE.ISNEW = 0)
            WHEN MATCHED THEN
                UPDATE SET PEO_ID = SOURCE.PEO_ID
            WHEN NOT MATCHED THEN
                INSERT (PEO_ID) VALUES(SOURCE.PEO_ID) 
            WHEN NOT MATCHED BY SOURCE THEN
                DELETE
            OUTPUT INSERTED.SGP_ID, SOURCE.SGP_ID, $ACTION) AS RqMERGE(TARGET_ID, SOURCE_ID, ACTIONS)
    WHERE    ACTIONS = 'INSERTED';
 
    --MERGING DES COMMENTAIRES DES GROUPES DE SAISONS
    MERGE    S_PROMO.T_SGP_COMMENT_SGC AS TARGET
    USING    (SELECT DISTINCT INS.TARGET_ID, LS.COMMENT
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            WHERE    LS.ISNEW = 1
            UNION
            SELECT    DISTINCT LS.SGP_ID, LS.COMMENT
            FROM    @LIST_SEASONS LS
            WHERE    LS.ISNEW = 0) AS SOURCE (SGP_ID, COMMENT)
        ON    TARGET.SGP_ID = SOURCE.SGP_ID
    WHEN MATCHED THEN
        UPDATE SET SGC_COMMENT = SOURCE.COMMENT
    WHEN NOT MATCHED THEN    
        INSERT(SGP_ID, SGC_COMMENT) VALUES (SOURCE.SGP_ID, SOURCE.COMMENT);
 
    --MERGING DES REMARQUES DES GROUPES DE SAISONS
    MERGE    S_PROMO.T_SGP_NOTE_SGN AS TARGET
    USING    (SELECT DISTINCT INS.TARGET_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            WHERE    LS.ISNEW = 1
            UNION
            SELECT    DISTINCT LS.SGP_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
            WHERE    LS.ISNEW = 0) AS SOURCE (SGP_ID, NOTE)
        ON    TARGET.SGP_ID = SOURCE.SGP_ID
    WHEN MATCHED THEN
        UPDATE SET SGN_NOTE = SOURCE.NOTE
    WHEN NOT MATCHED THEN    
        INSERT(SGP_ID, SGN_NOTE) VALUES (SOURCE.SGP_ID, SOURCE.NOTE);

**Lyche** · 05/08/2014, 16h03

et en plus ton code est sexy

**Kropernic** · 05/08/2014, 16h16

Et j'ai même réussi à y glisser une petite référence à Stargate-SG1.

Mais bon, je dois avouer que ce n'est pas totalement fait exprès.

**aieeeuuuuu** · 05/08/2014, 17h31

Je me demande du coup si le filtre sur les lignes insérée uniquement est si intéressant.
Car si la table @INSERTED contenait également les "vrais" identifiants des lignes mises à jour, ça simplifierai l'écriture des requetres MERGE suivantes, car alors par exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 USING    (SELECT DISTINCT INS.TARGET_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            WHERE    LS.ISNEW = 1
            UNION
            SELECT    DISTINCT LS.SGP_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
            WHERE    LS.ISNEW = 0) AS SOURCE (SGP_ID, NOTE)

deviendrait simplement (et sauf erreur de ma part

)

Code :

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

1
2
3
4
5
6
 
 USING    (SELECT DISTINCT INS.TARGET_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            ) AS SOURCE (SGP_ID, NOTE)

a voir l'impact sur les performances...

**Lyche** · 06/08/2014, 09h55

Lorsque tu fais un UPDATE, tu as une action de suppression et une action d'insertion qui se produit pour la ligne mise à jour.

Dans la table Inserted, tu auras les informations nouvellement insérées, et pour $Action "UPDATE", dans le même temps, tu as dans la table DELETED les informations contenues avant l'exécution du MERGE. Il est important de filtrer si le besoin est d'identifier les lignes nouvellement entrantes dans la base.

Cordialement,
Lyche

**Kropernic** · 06/08/2014, 10h05

Envoyé par Lyche

Lorsque tu fais un UPDATE, tu as une action de suppression et une action d'insertion qui se produit pour la ligne mise à jour.

Dans la table Inserted, tu auras les informations nouvellement insérées, et pour $Action "UPDATE", dans le même temps, tu as dans la table DELETED les informations contenues avant l'exécution du MERGE. Il est important de filtrer si le besoin est d'identifier les lignes nouvellement entrantes dans la base.

Cordialement,
Lyche

Oui oui mais en filtrant sur l'action inserted, je ne vais quand même pas me manger les valeurs de inserted pour les actions update j'espère. Non ?

**Lyche** · 06/08/2014, 10h22

Non, comme je t'expliquais au dessus, (peut-être mal), les lignes dans la table INSERTED qui proviennent de l'action UPDATE sont marqué à UPDATE. L'action global qui se produit lors d'un UPDATE est un DELETE/INSERT d'où la présence des informations dans les 2 tables de session. Mais, l'actions est bien un UPDATE

Au pire, essaye, reitre le filtre et regarde les informations qui remontent en rajouter une colonne Action dans ta table

**Kropernic** · 06/08/2014, 11h05

Envoyé par aieeeuuuuu

Je me demande du coup si le filtre sur les lignes insérée uniquement est si intéressant.
Car si la table @INSERTED contenait également les "vrais" identifiants des lignes mises à jour, ça simplifierai l'écriture des requetres MERGE suivantes, car alors par exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 USING    (SELECT DISTINCT INS.TARGET_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            WHERE    LS.ISNEW = 1
            UNION
            SELECT    DISTINCT LS.SGP_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
            WHERE    LS.ISNEW = 0) AS SOURCE (SGP_ID, NOTE)

deviendrait simplement (et sauf erreur de ma part

)

Code :

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

1
2
3
4
5
6
 
 USING    (SELECT DISTINCT INS.TARGET_ID, LS.NOTE
            FROM    @LIST_SEASONS LS
                        INNER JOIN @INSERTED INS
                            ON    LS.SGP_ID = INS.SOURCE_ID
            ) AS SOURCE (SGP_ID, NOTE)

a voir l'impact sur les performances...

Va falloir que j'analyse ça en détail ^^. Mais y a quelque chose à exploiter je pense.

**aieeeuuuuu** · 06/08/2014, 11h31

Envoyé par Lyche

Il est important de filtrer si le besoin est d'identifier les lignes nouvellement entrantes dans la base.

Il me semble justement que le besoin est de récupérer les lignes ajoutées ou modifiées (d'où le UNION dans les requêtes suivante, pour récupérer les nouvelles lignes dans le premier select, et les lignes modifiées dans le second)

Je dirai même qu'il pourrait être utile, lors du premier OUTPUT, de récupérer LS.Note dans @INSERTED afin de ne plus avoir besoin de la jointure avec @LIST_SEASONS...

**Kropernic** · 06/08/2014, 11h33

Envoyé par aieeeuuuuu

Il me semble justement que le besoin est de récupérer les lignes ajoutées ou modifiées (d'où le UNION dans les requêtes suivante, pour récupérer les nouvelles lignes dans le premier select, et les lignes modifiées dans le second)

Je dirai même qu'il pourrait être utile, lors du premier OUTPUT, de récupérer LS.Note dans @INSERTED afin de ne plus avoir besoin de la jointure avec @LIST_SEASONS...

Je vais regarder à tout ça mais j'ai un autre problème plus prioritaire qui m'est tombé dessus ce matin. Mais déjà un grand merci pour toutes ces propositions et le temps que vous m'avez tous les deux accordés.

Toujours des problèmes avec MERGE [2008R2]

Développement SQL Server

Discussions similaires

Partager

Partager