33.6. R�gles contre d�clencheurs

Beaucoup de choses pouvant se faire avec des d�clencheurs peuvent aussi �tre impl�ment�es en utilisant le syst�me de r�gles de PostgreSQL. Un des points qui ne pourra pas �tre impl�ment� par les r�gles en certains types de contraintes, notamment les cl�s �trang�res. Il est possible de placer une r�gle qualifi�e qui r��crit une commande en NOTHING si la valeur d'une colonne n'appara�t pas dans l'autre table. Mais alors les donn�es sont jet�es et ce n'est pas une bonne id�e. Si des v�rifications de valeurs valides sont requises et dans le cas o� il y a une erreur invalide, un message d'erreur devrait �tre g�n�r� et cela devra se faire avec un d�clencheur.

D'un autre c�t�, un d�clencheur qui est lanc� sur un INSERT pour une vue peut faire la m�me chose qu'une r�gle : placez les donn�es ailleurs et supprimez les insertions dans la vue. Mais, il ne pourra pas faire la m�me chose avec un UPDATE ou un DELETE parce qu'il n'y a pas de vraies donn�es sur la vue qui pourraient �tre parcourues. Du coup, le d�clencheur ne serait jamais appel�. Seule une r�gle pourra vous aider.

Pour les �l�ments qui peuvent �tre impl�ment�s par les deux, ce qui sera le mieux d�pend de l'utilisation de la base de donn�es. Un d�clencheur est ex�cut� une fois pour chaque ligne affect�e. Une r�gle manipule la requ�te ou en g�n�re une autre. Donc, si un grand nombre de lignes sont affect�es pour une instruction, ue r�gle lan�ant une commande suppl�mentaire sera certainement plus rapide qu'un d�clencheur appel� pour chaque ligne et qui devra ex�cuter ces op�rations autant de fois. N�anmoins, l'approche du d�clencheur est conceptuellement plus simple que l'approche de la r�gle et est plus facile � utiliser pour les novices.

Ici, nous montrons un exemple o� le choix d'une r�gle ou d'un d�clencheur joue sur une situation. Voici les deux tables :

CREATE TABLE ordinateur (
    nom_hote        text,    -- index�
    constructeur    text     -- index�
);

CREATE TABLE logiciel (
    logiciel        text,    -- index�
    nom_hote        text     -- index�
);

Les deux tables ont plusieurs milliers de lignes et les index sur nom_hote sont uniques. La r�gle ou le d�clencheur devrait impl�menter une contrainte qui supprime les lignes de logiciel r�f�ren�ant un ordinateur supprim�. Le d�clencheur utiliserait cette commande :

DELETE FROM logiciel WHERE nom_hote = $1;

Comme le d�clencheur est appel� pour chaque ligne individuelle supprim�e � partir de ordinateur, il peut pr�parer et sauvegarder le plan pour cette commande et passer la valeur nom_hote dans le param�tre. La r�gle devra �tre r��crite ainsi

CREATE RULE ordinateur_del AS ON DELETE TO ordinateur
    DO DELETE FROM logiciel WHERE nom_hote = OLD.nom_hote;

Maintenant, nous apercevons diff�rents types de suppressions. Dans le cas d'un

DELETE FROM ordinateur WHERE nom_hote = 'mypc.local.net';

la table ordinateur est parcourue par l'index (rapide), et la commande lanc�e par le d�clencheur pourrait aussi utiliser un parcours d'index (aussi rapide). La commande suppl�mentaire provenant de la r�gle serait

DELETE FROM logiciel WHERE ordinateur.nom_hote = 'mypc.local.net'
                       AND logiciel.nom_hote = ordinateur.nom_hote;

Comme il y a une configuration appropri�e des index, le planificateur cr�era un plan

Nestloop
  ->  Index Scan using comp_hostidx on ordinateur
  ->  Index Scan using soft_hostidx on logiciel

Donc, il n'y aurait pas trop de diff�rence de performance entre le d�clencheur et l'impl�mentation de la r�gle.

Avec la prochaine suppression, nous voulons nous d�barrasser des 2000 ordinateurs o� nom_hote commence avec old. Il existe deux commandes possibles pour ce faire. Voici l'une d'elle

DELETE FROM ordinateur WHERE nom_hote >= 'old'
                       AND nom_hote <  'ole'

La commande ajout�e par la r�gle sera

DELETE FROM logiciel WHERE ordinateur.nom_hote >= 'old' AND ordinateur.nom_hote < 'ole'
                       AND logiciel.nom_hote = ordinateur.nom_hote;

avec le plan

Hash Join
  ->  Seq Scan on logiciel
  ->  Hash
    ->  Index Scan using comp_hostidx on ordinateur

L'autre commande possible est

DELETE FROM ordinateur WHERE nom_hote ~ '^old';

ce qui finira dans le plan d'ex�cution suivant pour la commande ajout�e par la r�gle :

Nestloop
  ->  Index Scan using comp_hostidx on ordinateur
  ->  Index Scan using soft_hostidx on logiciel

Ceci monte que le planificateur ne r�alise pas que la qualification pour nom_hote dans ordinateur pourrait aussi �tre utilis�e pour un parcours d'index sur logiciel quand il existe plusieurs expressions de qualifications combin�es avec AND, ce qui correspond � ce qu'il fait dans la version expression rationnelle de la commande. Le d�clencheur sera appel� une fois pour chacun des 2000 anciens ordinateurs qui doivent �tre supprim�es, et ceci r�sultera en un parcours d'index sur ordinateur et 2000 parcours d'index sur logiciel. L'impl�mentation de la r�gle le fera en deux commandes qui utilisent les index. Et cela d�pend de la taille globale de la table logiciel, si la r�gle sera toujours aussi rapide dans la situation du parcours s�quentiel. 2000 ex�cutions de commandes � partir du d�clencheur sur le gestionnaire SPI prend un peu de temps, m�me si tous les blocs d'index seront rapidement dans le cache.

La derni�re commande que nous regardons est

DELETE FROM computer WHERE manufacurer = 'bim';

De nouveau, ceci pourrait r�sulter en de nombreuses lignes � supprimer de computer. Donc, le d�clencheur lancera de nouveau de nombreuses commandes via l'ex�cuteur. La commande g�n�r�e par la r�gle sera

DELETE FROM software WHERE computer.manufacurer = 'bim'
                       AND software.hostname = computer.hostname;

Le plan pour cette commande sera encore la boucle imbriqu�e sur les deux parcours d'index, en utilisant seulement un index diff�rent sur computer:

Nestloop
  ->  Index Scan using comp_manufidx on computer
  ->  Index Scan using soft_hostidx on software

Dans chacun de ces cas, les commandes suppl�mentaires provenant du syst�me de r�gles seront plus ou moins ind�pendantes du nombre de lignes affect�es en une commande.

Voici le r�sum�, les r�gles seront seulement significativement plus lentes que les d�clencheurs si leur actions r�sultent en des jointures larges et mal qualifi�es, une situation o� le planificateur �choue.