Discussion :

[Grantoumaigr]

Bonjour,

je vais tout d'abord vous expliquer ma problématique car la solution des trigger n'est peut-être pas la meilleure et je pense que ce que je veux faire beaucoup de monde l'a déjà fait avant moi.

Voilà, je fais un import dans ma base Postgres de données venant de Documentum (ce n'est qu'un détail).
Chaque document est identifié par un id unique et un id commun à sa série de documents et à l'intérieur de cette série seul un document est définit en tant que version courante.
J'ai donc dans ma table "document" les 2 ids de chaque document (celui propre au document et celui commun à sa série documentaire) et un booléen qui indique si il est la version courante de la série.
Pour être sûr qu'il n'y est qu'une version courante par série documentaire j'ai donc un trigger qui est déclenché à chaque action (insert , update, delete) et qui met à jour la version courante de la série. Donc en fait, si un document est inséré en tant que nouvelle version courante par exemple, le trigger va être déclenché pour mettre à jour l'ancienne version courante (mettre son booléen à false)... ce qui va de nouveau déclencher le trigger et ainsi de suite.
J'ai donc voulu désactiver le trigger une fois qu'il a été lancé pour ne pas qu'il se déclenche en cascade mais pgAdmin me dit que ce n'est pas possible (ce que je comprends) et refuse de le valider.

Alors comment faire ?

[estofilo]

Une solution serait de coder les fonctionnalités d'insertion, mise à jour, suppression dans des fonctions en remplacement de l'appel direct à insert/update/delete + triggers qui semblent inadaptés pour ce que tu veux faire.

Et pour être sûr de la partie "unicité d'une version courante par série", un index unique serait sans doute la meilleure solution.

[SQLpro]

Chaque document est identifié par un id unique et un id commun à sa série de documents et à l'intérieur de cette série seul un document est définit en tant que version courante.
J'ai donc dans ma table "document" les 2 ids de chaque document (celui propre au document et celui commun à sa série documentaire) et un booléen qui indique si il est la version courante de la série.

C'est votre modélisation qui n'est pas bonne.
Il faut :
1) une table document
2) une table version
Dans la table document vous aurez l'id générique de la série des documents format les différentes version
Dans la table version vous aurez les identifiant des différentes versions avec une clef étrangère venant de la table document
Il ne vous suffit pllus que de rajouter à votre table document une clef étrangère inverse (de version) pour savoir quelle est la version actuellement valide de votre document.
Donc pas besoin de trigger qui en plus d'être difficle à gérer comme vous l'avez constaté serait peu performant !

A +

[SQLpro]

C'est votre modélisation qui n'est pas bonne.
Il faut :
1) une table document
2) une table version
Dans la table document vous aurez l'id générique de la série des documents format les différentes version
Dans la table version vous aurez les identifiant des différentes versions avec une clef étrangère venant de la table document
Il ne vous suffit plus que de rajouter à votre table document une clef étrangère inverse (de version) pour savoir quelle est la version actuellement valide de votre document.
Donc pas besoin de trigger qui en plus d'être difficile à gérer comme vous l'avez constaté serait peu performant !

A +

[Grantoumaigr]

Bonjour,

estofilo: Merci de ta réponse, je voulais éviter ça afin de sécuriser mes données: si quelqu'un décide de faire un update directement dans la base ou un insert de masse sans passer par la fonction.

je ne suis pas sûr d'avoir tout compris à ta réponse SQL Pro.
En fait, tu veux:
- que je crée une table "document" contenant seulement l'id commun,
- et une table "version" contenant l'id unique, l'id commun (pour faire la clé étrangère) ainsi que les attributs de ma version (en gros, ma table actuelle).

Je ne vois pas comment cela va m'aider à trouver la version courante.
Ou bien alors je dois rajouter dans la table "document" une autre colonne "id_current_version" contenant la clé unique de la version courante de chaque document; mais alors le problème restera le même: comment mettre à jour cette colonne automatiquement.