Discussion :

[Nicos42]

Bonjour,

Je suis débutant en sql aussi merci de votre indulgence...
Dans le cadre d'un petit développement, je dois pouvoir mettre à jour une table SQL depuis une autre. Cela doit se faire dans un trigger.
Pour les 2 tables, un identifiant (ID) permet de faire l'inner join.
Problème, ma table cible contient une ligne par ID avec 5 champs (du même enregistrement) à mettre à jour : vb1, vb2, vb3, vb4 et vb5
alors que la table source contient une ligne par ID ET par valeur de vb que je dois récupérer...
Je cale!
Merci de vos suggestions.

[al1_24]

ça s'appelle de la dénormalisation et saimal

[aieeeuuuuu]

Bonjour,

Cherchez avec le mot clef PIVOT.
Vous trouverez des exemples sur le forum (et des explications indiquant pourquoi il ne faut pas le faire )

[iberserk]

si le nombre de colonne (5) est figé

vous pouvez aussi procéder autrement mais il me faudrait la structure de votre deuxième table

[Nicos42]

Oui le nb de colonnes est figé à 5 dans mon cas.
La 2ème table est du type :
ID, vb ou je peux avoir plusieurs enregistrements avec un ID identique mais comportant des vb différents. Ce sont ces valeurs que je dois récupérer dans la 1ère table...
Merci de votre aide

[Nicos42]

Précisions : dans la table2, les valeurs de vb sont variables pour chaque ID et chaque enregistrement...

[iberserk]

Structure de la table merci: liste des colonnes par exemple

[fsmrel]

Nicos42,

Votre table CIBLE contient 5 attributs vb1, vb2, ..., vb5 constituant une liste ordonnée par construction.

Votre table SOURCE contient 5 lignes, c’est un ensemble de 5 paires <ID, vb_j> et comme dans tout ensemble dans le contexte relationnel, l’ordre des éléments est quelconque, il n'est pas significatif : comment savoir parmi ces 5 paires de la table SOURCE quelle est celle qui met à jour par exemple l’attribut vb1 cible ?

Avant de vous enliser à cause d’une approche hasardeuse de la modélisation, il est temps de repartir à zéro, casser la structure de la table CIBLE et bâtir un modèle dans l’esprit du modèle relationnel de données, la table SOURCE doit être structurée de façon saine, à l’image de la table SOURCE (une paire( ID, vb) par ligne). Pour les deux tables, il faut aussi ajouter un attribut complétant l'identifiant ID, car vos attributs vb sont modifiables, donc impropres à participer à l'identification.

S’il s’agit de présenter l’information sous la forme (ID, b1, v2, ..., vb_n), il existe des solutions pour cela (CUBE, UNION, ....), mais cela ne doit avoir aucune incidence sur la structure des tables.

[Nicos42]

Dans mon exemple (la vraie table à plus de colonnes) :
ID et VB où ID est l'identifiant qui me permet de regrouper les différents VB

Ce qui pourrait être TABLE2 :

ID = 1;VB = 12
ID = 1; VB = 15
ID = 2; VB = 10
ID = 2; VB = 12
ID = 2; VB = 18
ID = 2; VB = 15
ID = 3; VB = 20
ect...

Alors que Table1 :
ID = n; VB1 = à compléter; VB2 = à compléter; VB3 = à compléter; VB4 = à compléter; VB5 = à compléter;

Ce que je veux obtenir :
Table1 :

ID = 1; VB1=12;VB2=15;;;
ID = 2;VB1=10;VB2=12;VB3=18;VB4=15;;
ID = 3;VB1=20;;;;

[al1_24]

Et pourquoi la valeur 18 pour l'ID 2 serait-elle placée dans la colonne VB3 et pas VB4 ou VB2 ?

[Nicos42]

En réponse à la question de AL1_24, l'ordre n'aura pas d'importance. Il faut juste commencer par renseigner VB1 puis VB2 puis VB3 puis etc... si tant est qu'il y ait plusieurs VB pour un même ID

[fsmrel]

Une incidente :

ça s'appelle de la dénormalisation et saimal

En fait la table en cause est normalisée, mais, pour suivre Chris Date, elle pêche par ce qu’on appelle en franglais « optimisation », mais je suis d’accord que ça aussi saimal, et même certains chez IBM ne sont pas bien au courant à ce sujet (du reste, ils s'en tapent)...

[fsmrel]

Ce qui pourrait être TABLE2 :
ID = 1; VB = 12
ID = 1; VB = 15
ID = 2; VB = 10
ID = 2; VB = 12
ID = 2; VB = 18
ID = 2; VB = 15
ID = 3; VB = 20
Etc...

Et si l’on avait les valeurs suivantes (doublons) :

ID = 1; VB = 12
ID = 1; VB = 12
Etc.

TABLE2 a-t-elle une clé primaire ? Si oui, qu’elle est-elle ? (A défaut c’est un sac et les opérateurs relationnels sont mis en échec puisqu’ils opèrent sur des ensembles).

[Nicos42]

En fait Table2 est une vue issue d'une autre base. Dans tous les cas, il ne peut y avoir de doublon tel que l'exemple cité...

[fsmrel]

En fait Table2 est une vue issue d'une autre base. Dans tous les cas, il ne peut y avoir de doublon tel que l'exemple cité...

C’est vous qui le dites, mais je ferai observer qu’une vue SQL n’est pas dotée de clé, donc rien de plus facile que d’y injecter des doublons, d’en faire un sac.

Quoi qu’il en soit, vous voulez que l’opération se fasse au moyen d’un trigger. Celui –ci porte donc sur la table CIBLE.

Mais pour activer ce trigger, il faut exécuter un INSERT : à quoi ressemble celui-ci ?

[Nicos42]

En fait la vue en question serait Table2 dans mon exemple précédent.

Le trigger est créé sur Table1 car Table1 est mise à jour par une autre tâche et sur cette tâche que je déclenche le trigger.
L'objectif est que ce trigger permette de mettre à jour Table1 avec les 5 champs POTENTIELS de VB1,2,3,4,5 pour un ID commun aux 2 tables.

J'ai essayé INNER JOIN, MERGE INTO WHEN MATCHED, mais je coince toujours sur le fait que j'ai dans Table2 plusieurs lignes (1 ou 2 ou 3 ou 4 ou 5) pour un même ID alors que dans Table1 je veux une ligne par ID identique avec plusieurs champs VB1,2,3,4,5 avec VBn = NULL si dans Table2 je n'ai que n-1 ligne pour un même ID.

J'espère arrivé à me faire comprendre...pardonnez ma méconnaissance de SQL

[Nicos42]

Précision : je peux avoir plus de 5000 valeurs différentes de VB....

[fsmrel]

Bonsoir,

ma table cible contient une ligne par ID avec 5 champs (du même enregistrement) à mettre à jour : vb1, vb2, vb3, vb4 et vb5

Supposons que votre table cible ressemble à quelque chose comme ceci :

TABLE CIBLE

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE CIBLE 
(
        ID              INT             NOT NULL
      , vb1             VARCHAR (4)                  
      , vb2             VARCHAR (4)      
      , vb3             VARCHAR (4)                  
      , vb4             VARCHAR (4)                  
      , vb5             VARCHAR (4)                  
    , CONSTRAINT CIBLE_PK PRIMARY KEY (ID)                    
) ;

Et que votre table source ressemble à quelque chose comme ceci :

TABLE SOURCE

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE SOURCE 
(
        K               INT             NOT NULL 
      , ID              INT             NOT NULL
      , vb              VARCHAR (4)     NOT NULL  
    , CONSTRAINT SOURCE_PK PRIMARY KEY (K)             
) ;

Avec les valeurs :

Code :

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

1
2
3
4
5
6
7
8
9
K    ID    vb
-------------
1     1    12
2     1    15
3     2    10
4     2    12
5     2    18
6     2    15
7     2    11

Vous pourriez mettre en œuvre une table à l’image de SOURCE, mais où l’on se sert de l’identification relative :

TABLE SOURCE2

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE SOURCE2
(
        ID              INT             NOT NULL
      , IdRel           INT             NOT NULL
      , vb              VARCHAR (4)     NOT NULL  
    , CONSTRAINT SOURCE2_PK PRIMARY KEY (ID, IdRel)
) ;

Cette table SOURCE2 serait à peupler à partir de la table SOURCE, avec pour résultat :

Code :

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

1
2
3
4
5
6
7
8
9
ID    IdRel    vb
-----------------
 1        1    12
 1        2    15
 2        1    10
 2        2    12
 2        3    18
 2        4    15
 2        5    11

Cette fois-ci, avec la colonne IdRel , on aura numéroté les lignes relativement à la colonne ID. Pour réaliser cette opération, les cracks de SQL sauront vous conseiller, en utilisant des fonctions ad-hoc (RowId(), ... ?), ou un trigger, sinon ça sera la méthode bourrin (parcours de la table SOURCE par curseur, pour alimenter la table SOURCE2).

A partir de SOURCE2, la mise à jour de la table CIBLE devient simple :

Code SQL :

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

1
2
3
4
5
6
7
 
UPDATE CIBLE 
    SET vb1 = (SELECT vb FROM SOURCE2 WHERE CIBLE.ID = SOURCE2.ID AND IdRel = 1) 
      , vb2 = (SELECT vb FROM SOURCE2 WHERE CIBLE.ID = SOURCE2.ID AND IdRel = 2) 
      , vb3 = (SELECT vb FROM SOURCE2 WHERE CIBLE.ID = SOURCE2.ID AND IdRel = 3)
      , vb4 = (SELECT vb FROM SOURCE2 WHERE CIBLE.ID = SOURCE2.ID AND IdRel = 4)
      , vb5 = (SELECT vb FROM SOURCE2 WHERE CIBLE.ID = SOURCE2.ID AND IdRel = 5) ;

Tout ceci est assez lourd, mais de mon côté je n’utilise pas SQL Server tous les jours, un crack saura alléger tout ça...

A suivre...

[SQLpro]

Déjà faire un déclencheur pour dupliquer des données alors qu'il est possible de faire cela par une vue est une imbécilité, mais en plus lorsque cela à pour vocation de faire de la cosmétique, c'est de la démence !

A +

[fsmrel]

Salut Fred,


Merci de ta visite, je pense que Nicos42 sera fort ravi que tu présentes ta solution !