MySQL 5.0 : Un SGBDR mature ? — (part 3/4)
Procédures stockées et fonctions
Les procédures stockées sont des listes de commandes qui peuvent être compilées et stockées sur le serveur. Elles permettent de déplacer une partie de la logique métier d’une application de base de données du client vers le serveur. Les clients n’ont plus besoin de soumettre à nouveau toute la commande, mais font simplement référence à la procédure stockée.
Cela se traduit par une amélioration de la sécurité, une diminution de la redondance du code, et une augmentation des performances.
Des procédures stockées pour améliorer la sécurité
Elles peuvent fournir une protection contre les attaques d’injection SQL, principalement contre celles qui utilisent un opérateur AND ou OR pour ajouter des commandes à une valeur de paramètre d’entrée valide. Les programmes clients n’accédant plus directement aux tables. Toutes les opérations de gestion des données sont effectuées via des procédures stockées.
Des procédures stockées pour centraliser les requêtes
Différentes applications peuvent accéder à la même base de données et avoir les mêmes fonctionnalités. Les procédures stockées peuvent alors servir à factoriser ce code SQL commun ce qui permet de diminuer la redondance et facilite la maintenance du code.
Des procédures stockées pour augmenter les performances
Les commandes n’ont pas à être analysées plusieurs fois, elles sont (pré)compilées sur le serveur et bien moins d’informations transitent sur le réseau, le trafic y est donc limité.
Les procédures stockées sont particulièrement utiles quand les clients qui accèdent à la base de données ne sont pas sur le même serveur.
Le principal inconvénient des procédures stockées, et qu’elles nous rendent complètement dépendantes de l’éditeur de la base de données, puisqu’il n’existe pas de langage universel de développement de procédures stockées.
Une migration simplifiée par le respect du standard SQL 2003
Les procédures stockées de MySQL 5 respectent certaines recommandations du standard SQL 2003. La syntaxe est donc très proche de la syntaxe de DB2 ce qui permet une migration facile entre les deux outils. La migration en provenance d’Oracle ou de MS SQL Server impliquera plus de travail manuel étant donné que leurs bases de données ne respectent pas autant le standard.
Astuce : Pour migrer d’Oracle vers MySQL on peut utiliser les outils de migration Oracle vers DB2 puis passer de DB2 à MySQL qui sont très proches.
Syntaxe
CREATE [DEFINER = { user | CURRENT_USER }] PROCEDURE sp_name([parametres]) LANGUAGE SQL | [NOT] DETERMINISTIC | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA } | SQL SECURITY { DEFINER | INVOKER } | COMMENT 'string' routines
(suite ->)
Architecte Solution Cloud chez Oracle
MySQL Geek, Architecte, DBA, Consultant, Formateur, Auteur, Blogueur et Conférencier.
—–
Blog: www.dasini.net/blog/en/
Twitter: https://twitter.com/freshdaz
SlideShare: www.slideshare.net/freshdaz
Youtube: https://www.youtube.com/channel/UC12TulyJsJZHoCmby3Nm3WQ
—–
[…] UPDATEABLE_KEY est une fonctionnalité de MySQL permettant de modifier une clef primaire par le biais d’une vue. (suite ->) […]
[…] (<- précédent) […]