La principale utilité des triggers et des procédures stockées, c'est de faire de la validation de données pour garantir que ta base ne puisse pas se retrouver dans un état incohérent. Ce n'est plus à la partie applicative d'appliquer les contraintes d'intégrité mais ça relève directement du SGBD. Ça permet de faire des trucs un peu plus chiadés que les contraintes SQL de bases.
===> ça évite de se retrouver avec une base incohérente à cause d'un bogue dans le client ou d'un crétin qui a fait une requête foireuse.
Les autres utilisations couvrent l'encapsulation de la logique métier donc moins de traitements à faire côté client, améliorer les performances en réduisant les échanges, néanmoins ça a un coût côté serveur. Mais également logguer, faire de la réplication, gérer plus finement les accès.
Postgres a un support très complet des triggers et procédures stockés que l'on peut écrire en PL/pgSQL (un langage de programmation inspiré du PL/SQL d'Oracle) ou en Python, Perl, etc ...
MySQL a un support assez récent et relativement pauvre comparé à Postgres, mais suffisant pour la plupart des cas d'utilisations.
Pour de l'optimisation pure, tu as d'autres leviers à ta disposition à commencer par une bonne conception et l'implantation. Et ne jamais oublier que tout se paie avec un SGBD !
# Intégrité de l'information
Posté par GeneralZod . En réponse au message Procédure stockées. Évalué à 3.
===> ça évite de se retrouver avec une base incohérente à cause d'un bogue dans le client ou d'un crétin qui a fait une requête foireuse.
Les autres utilisations couvrent l'encapsulation de la logique métier donc moins de traitements à faire côté client, améliorer les performances en réduisant les échanges, néanmoins ça a un coût côté serveur. Mais également logguer, faire de la réplication, gérer plus finement les accès.
Postgres a un support très complet des triggers et procédures stockés que l'on peut écrire en PL/pgSQL (un langage de programmation inspiré du PL/SQL d'Oracle) ou en Python, Perl, etc ...
MySQL a un support assez récent et relativement pauvre comparé à Postgres, mais suffisant pour la plupart des cas d'utilisations.
Pour de l'optimisation pure, tu as d'autres leviers à ta disposition à commencer par une bonne conception et l'implantation. Et ne jamais oublier que tout se paie avec un SGBD !