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

[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

[iberserk]

Structure de la table merci: liste des colonnes par exemple