non, parce que ça veut dire que pour inserer les elements il faille explicitement appeler cette procédure stockée. Et ça veut donc dire que si, pour une raison ou une autre, à un moment il soit fait directement un insert dans la table, la procédure n'est pas appelée. Du coup, cohérence des données cassée.
L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.
Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.
Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.
[^] # Re: Problème de clés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance MYSQL. Évalué à 3.
L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.
Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.
Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.