Discussion :

[Ikebukuro]

Bonjour les experts,

Juste une question de culture générale : pourquoi pour un trigger sur vue le code de l'ordre SQL (INSERT, UPDATE, DELETE) est remplacé par le code du trigger alors que pour une table il est exécuté avant ou après l'ordre SQL déclenchant le trigger?

Sinon, dans le code du trigger sur vue, est-il possible, facilement, de récupérer l'ordre SQL qui a déclenché le trigger?

[SQLpro]

Normalement les applications ne devraient jamais attaquer directement les tables. En effet, les vues fournissent une couche d'abstraction qui rend plus souple la modification du modèle de données et globalement l'architecture de la base. Mais il est important que les vues soient "misajourables" (règle de Codd n°6). Certaines peuvent l'être directement, d'autres plus complexes doivent passer par des déclencheurs de type INSTEAD OF.

À noter l'ensemble des objets Vues + Routines SQL (Déclencheurs, Procédures, UDF...) s'appelle le Modèle Externe de Données. A lire : http://www.eyrolles.com/Informatique...-9782212142068

A +

[mnitu]

Ces sont deux choses assez différentes en fait.
Les triggers pour les vues existent uniquement pour permettre la modification des vues qui autrement ne sont pas modifiables directement. Comme ces modifications impacteront forcement la(les) table(s) supportant ces vues il n'y aucun raison d'avoir le même comportement avec les triggers des tables.

[Ikebukuro]

Houla, ta réponse mnitu n'est pas claire en ce qui me concerne

Quand tu dis "Les triggers pour les vues existent uniquement pour permettre la modification des vues qui autrement ne sont pas modifiables directement", je ne suis aps d'accord, je dirais "Les triggers pour les vues existent pour empêcher la modification des vues" puisque le code du trigger sur vue annule et remplace l'ordre SQL de mise à jour de la vue.

En outre, d'après ce que tu dis, je devine la chose suivante "Dans le cas des vues portant sur plusieurs tables, il n'est pas possible de mettre à jour toutes les tables sous-jacentes via un ordre SQL simple comme pour les tables avec INSERT, DELETE, UPDATE. Pour remédier à ce problème, Oracle a créé des triggers sur vues pour éviter un message d'erreur sur la mise à jour et permettre au développeur de coder la mise à jour sur les différentes tables de la vue".

Si ce que je viens de dire est OK, il faut impérativement que dans le trigger sur vue, on puisse récupérer l'ordre SQL saisi pour, à partir de lui, générer N ordres SQL de mise à jour des tables sous-jacentes.
MAIS comment puis-je récupérer cet ordre SQL? Pour les triggers sur évènements système Oracle met à notre disposition des variables d'environnement pour faciliter notre travail mais là, pour les triggers sur vue... je ne vois pas comment faire.

[SQLpro]

MAIS comment puis-je récupérer cet ordre SQL? Pour les triggers sur évènements système Oracle met à notre disposition des variables d'environnement pour faciliter notre travail mais là, pour les triggers sur vue... je ne vois pas comment faire.

De la même manière, en jouant sur les pseudo table par l’intermédiaire de OLD et NEW....

A +

[Ikebukuro]

Houla, ça me chauffe l'esprit tout ça
Je file sur ma base pour voir comment récupérer cet ordre SQL!

[EDIT]
Je viens de tomber sur ce code et ça me plait bien.
Avec OLD et NEW, comme tu dis, on pourrait modifier les tables sous-jacentes de la vue.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
create or replace trigger v_emp_iu
  2  INSTEAD OF UPDATE
  3  on v_employee
  4  declare
  5      v_error VARCHAR2(256);
  6  begin
  7      if updating('ID')
  8      then
  9          v_error:='You cannot update the PK!';
 10          raise_application_error (-20999,v_error);
 11      else
 12          update employee
 13          set first_Name = :new.first_Name
 14          where id = :old.id;
 15      end if;
 16  end;

[mnitu]

On peut considérer qu'en général une vue n'est pas modifiable bien que des exceptions existent. Mieux dit certaines vue sont modifiable en mode inhérent et d'autres pas. Pour les vue qui ne sont pas modifiable vous pouvez créer des triggers de type instead of pour permettre leur modification.

L'exemple que vous avez trouvé est à coté de la plaque: la notion de clé primaire n'existe pas pour une vue mais pour une table. Si quelqu'un souhaite empêcher la modification de la clé primaire de la table il pourrais envisager d'écrire un trigger sur la table en question. Si cela est fait sur une vue basée sur cette table cela n'empêcherait pas la mise à jours de la table directement.

Vous n'avez pas besoin de récupérer aucun ordre SQL dans trigger instead of. Si vous avez besoin d'écrire un trigger de ce type alors les actions que le trigger devrait faire sont claires pour vous le développeur: vous connaissez les tables et la définition de la vue.

[Ikebukuro]

Merci pour la réponse mnitu, à nouveau c'est très clair!

[SQLpro]

On peut considérer qu'en général une vue n'est pas modifiable bien que des exceptions existent. .

Non, je peut pas laisser passer cette affirmation parfaitement fausse !

pour information, Franck Edgar Codd, inventeur des SGBD relationnel indique dès 1985 dans ses articles sur les règles de Codd :
"
Rule 6: The view updating rule : All views that are theoretically updatable are also updatable by the system.
"
Lisez aussi les explications et exemples que j'ai donné ici :
http://sqlpro.developpez.com/SGBDR/ReglesCodd/

A +

[mnitu]

On peut considérer qu'en général une vue est modifiable bien que des exceptions existent.