Trigger sur table SQL (Express 2008 R2)

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.

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

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

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

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

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

Structure de la table merci: liste des colonnes par exemple

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.

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

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

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

Une incidente :

Citation:

---

Envoyé par al1_24

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

---

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

Citation:

---

Envoyé par Nicos42

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

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

Citation:

---

Envoyé par 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é...

---

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 ?

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

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

Bonsoir,

Citation:

---

Envoyé par Nicos42

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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

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 +

Salut Fred,


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

Allons y pour les grosses merde :

Code:

---

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

---

J'ai repris ta table pour pas me fouler....

Et la vue :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE VIEW V_MA_GROSSE_MERDE_COSMÉTIQUE AS SELECT K, CASE WHEN ID = 1 THEN vb END AS vb1, CASE WHEN ID = 2 THEN vb END AS vb2, CASE WHEN ID = 3 THEN vb END AS vb3, ... CASE WHEN ID = N THEN vb END AS vbN FROM SOURCE;

---

A +

Fred,



Je crains que ta solution ne réponde pas au problème posé. On est en présence d’une sorte de modulo 5, et ce qu’on doit produire :

Pour ID = 1 : vb11, vb12, vb13, vb14, vb15
Pour ID = 2 : vb21, vb22, vb23, vb24, vb25
...
Pour ID = i : vbi1, vbi2, vbi3, vbi4, vbi5
...
Pour ID = n : vbn1, vbn2, vbn3, vbn4, vbn5

Alors que selon ta requête, pour ID = i on produirait plutôt vbi.

P.-S. J’ai essayé ta requête avec SQL Server 2008 lequel annonce : « Syntaxe incorrecte vers le mot clé 'AS'. »

Citation:

---

Envoyé par fsmrel

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

---

En fait, l'instruction permettant de peupler la table SOURCE2 se code de façon simple :

Code:

---

1 2 3

INSERT INTO SOURCE2 SELECT ID, ROW_NUMBER() OVER (PARTITION BY ID ORDER BY vb), vb FROM SOURCE ;

---

En effet,

Du coup, on peut même se passer de cette table (SOURCE2) en la mettant directement en CTE, et faire la mise à jour ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

WITH CTE AS ( SELECT ID, ROW_NUMBER() OVER (PARTITION BY ID ORDER BY vb) AS N, vb FROM SOURCE ) UPDATE C SET vb1 = [1] , vb2 = [2] , vb3 = [3] , vb4 = [4] , vb5 = [5] FROM CIBLE C INNER JOIN CTE PIVOT(MAX(vb) FOR N IN([1], [2], [3], [4], [5])) P ON P.ID = C.ID

---

Mais effectivement, il faudra songer a revoir le modèle !

OK aieeeuuuuu, vous avez été plus rapide, mais abondance de biens ne nuit point...


Voici ce que j'avais prévu :


Reprise de la séquence, en pouvant cette-fois-ci utiliser une vue :


TABLE CIBLE

Code:

---

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

---

TABLE SOURCE

Code:

---

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

---

Utilisation d’une vue qu’on peut nommer SOURCE2 :

Code:

---

1 2 3

CREATE VIEW SOURCE2 (ID, IdRel, vb) AS SELECT ID, ROW_NUMBER() OVER (PARTITION BY ID ORDER BY vb), vb FROM SOURCE ;

---

Mise à jour de la cible :

Code:

---

1 2 3 4 5 6

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)

---

aieeeuuuuu, votre solution est de toute façon la plus élégante ;)

Merci de votre aide