Discussion :

[Baptiste443]

Bonjour,

je bloque sur un problème depuis quelque temps et j'aimerai savoir si quelqu'un y a déjà été confronté (surement) et s'il ou elle a trouvé une solution.

Voici mon problème :
dans oracle 12c j'ai une relation n:n entre une table de points et une table d'informations ce qui donne :

TA_TABLE1
id Number(38,0) PK,
geom sdo_geometry

TA_RELATION
id NUMBER(38,0) PK
fid_table1 FK
fid_table2 FK

TA_TABLE2
id NUMBER(38, 0) PK,
code VARCHAR2(50)

Je voudrais pouvoir insérer des données dans ces trois tables simultanément afin de respecter les contraintes d'intégrité de la table pivot. Donc, si l'utilisateur renseigne le code dans la table TA_TABLE2 et qu'il créé son point dans la table TA_TABLE1(via un formulaire qgis), je voudrais pouvoir enregistrer dans la même transaction les clés primaires des tables TA_TABLE1 et TA_TABLE2 dans les clés étrangères de la table TA_RELATION (le trigger se fait sur TA_TABLE2 car parfois l'utilisateur ne connaîtra pas le code).
Mais si j'arrive à insérer le :new.id de TA_TABLE2 dans TA_RELATION.fid_table2 via un trigger, je n'arrive pas à récupérer le new.id de TA_TABLE1 et à l'insérer dans la ligne correspondante. L'ennui c'est que dans le trigger (si je ne me trompe pas) les variables :new et :old ne porte que sur la table sur laquelle porte le trigger.
Par ailleurs je ne peux pas utiliser la séquence d'incrémentation de l'id de TA_TABLE1 en faisant SEQ_TABLE1.nextval puisque cela reviendrait à créer un nouvel id et non à récupérer celui qui est en cours d'insertion, l'utilisation de currval ne marche pas non plus puisque l'id n'est pas encore validé.

L'autre solution serait de faire deux formulaires remplis séparément puis de faire un trigger d'insertion dans la table TA_RELATION, mais je préfèrerai n'avoir qu'un seul formulaire car autrement il faudrait que l'utilisateur remplisse d'abord le formulaire de TA_TABLE1, puis celui de TA_TABLE2 et je voudrais éviter qu'il se trompe en le faisant dans le l'autre sens (ce qui ne permettrait pas d'associer le nouveau code au nouveau point, mais le nouveau code à l'avant dernier point).

Je sais que la clause RETURNING INTO permet de récupérer une valeur en mutation et je pense que si je créé une fonction avec cette clause je pourrais récupérer le nouvel id de TA_TABLE1, mais je ne sais pas comment faire. Auriez-vous une idée ?

Voici le code du trigger que j'utilise pour le moment :

Code :

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

1
2
3
4
5
6
7
create or replace TRIGGER TEST_TABLE2
AFTER INSERT ON TA_TABLE2
FOR EACH ROW
    BEGIN
        INSERT INTO TA_TABLE_RELATION(fid_table2)
            VALUES(:new.id);
END;

[skuatamad]

L'alimentation d'une table d'association ne se fait pas via trigger.
Dans l'application vous savez quelle association doit être créée, et donc dans la transaction vous insérez des lignes dans table1 et/ou table2 et dans la relation.

PS : pas besoin de id NUMBER(38,0) PK dans TA_RELATION, c'est le couple (fid_table1 FK, fid_table2 FK) qui doit constituer la PK.

[vanagreg]

Bonjour,

Tu n'y arriveras pas par trigger avec ce modèle. Il faut que tu gères dans l'appli l'insertion. Tu peux utiliser un insert multi-tables avec des contraintes fk déférées sur ta table TA_RELATION.

[Baptiste443]

Bonjour skuatamad,
Bonjour vanagreg,

merci pour vos réponses rapides !
C'est bien ce que je pensais : ça se joue du côté de l'application.

Merci vanagreg pour l'idée des contraintes déférées, je vais essayer.

Je suis d'accord avec toi skuatamad concernant la clé primaire composée de TA_RELATION, c'est juste que les admin de ma boîte ont mis comme règle de toujours créer un champ id dans les tables, du coup je ferai une PK sur les trois champs.

[skuatamad]

Non, pas sur 3, ça voudrait dire qu'il peux y avoir des doublons, par contre pourquoi pas une contrainte d'unicité sur le couple (fid_table1 FK, fid_table2 FK).

[Baptiste443]

C'est effectivement une bonne idée pour l'un de mes modèles et je compte ajouter une contrainte de non nullité, mais pas pour le deuxième où il y aura des doublons de la FK de TA_TABLE2 dans TA_RELATION. Ce second modèle servira à répertorier les actions des utilisateurs sur les objets, ce qui signifie qu'un utilisateur pourra créer, modifier ou supprimer plusieurs objets, voire le même.

D'autres parts j'ai fait mes associations et mon formulaire dans QGIS et la table TA_RELATION se remplit effectivement avec la FK de la table TA_TABLE2, mais pas avec celle de la table TA_TABLE1 ce qui est étrange puisque qu'il y a les mêmes triggers d'incrémentation de la PK dans chaque table. Je pense que le soucis provient de l'application et non de la base.