Quand utiliser des procédures
Il existe un certain nombre d’avantages à l’utilisation de procédures, tout en fonction du fait que l’utilisation de procédures déplace les instructions SQL de l’application vers la source de données. Ce qui est laissé dans l’application est un appel de procédure interopérable. Les avantages sont les suivants :
Les procédures de performances sont généralement le moyen le plus rapide d’exécuter des instructions SQL. Comme l’exécution préparée, l’instruction est compilée et exécutée en deux étapes distinctes. Contrairement à l’exécution préparée, les procédures sont exécutées uniquement au moment de l’exécution. Ils sont compilés à un moment différent.
Règles d’entreprise Une règle d’entreprise est une règle sur la façon dont une entreprise fait affaire. Par exemple, seule une personne avec le titre Sales Person peut être autorisée à ajouter de nouvelles commandes. Le placement de ces règles dans des procédures permet aux entreprises individuelles de personnaliser les applications verticales en réécritant les procédures appelées par l’application sans avoir à modifier le code de l’application. Par exemple, une application d’entrée de commande peut appeler la procédure InsertOrder avec un nombre fixe de paramètres ; exactement la façon dont InsertOrder est implémentée peut varier d’une entreprise à l’autre.
La replaceabilité étroitement liée au placement de règles métier dans les procédures est le fait que les procédures peuvent être remplacées sans recompiler l’application. Si une règle métier change une fois qu’une entreprise a acheté et installé une application, l’entreprise peut modifier la procédure contenant cette règle. Du point de vue de l’application, rien n’a changé ; elle appelle toujours une procédure particulière pour accomplir une tâche particulière.
Les procédures SQL spécifiques au SGBD permettent aux applications d’exploiter sql spécifique au SGBD et restent toujours interopérables. Par exemple, une procédure sur un SGBD qui prend en charge les instructions de contrôle de flux dans SQL peut intercepter et récupérer des erreurs, tandis qu’une procédure sur un SGBD qui ne prend pas en charge les instructions de contrôle de flux peut simplement renvoyer une erreur.
Les procédures survivent aux transactions sur certaines sources de données, les plans d’accès pour toutes les instructions préparées sur une connexion sont supprimés lorsqu’une transaction est validée ou restaurée. En plaçant des instructions SQL dans des procédures, qui sont stockées définitivement dans la source de données, les instructions survivent à la transaction. Si les procédures survivent dans un état préparé, partiellement préparé ou non préparé est spécifique au SGBD.
Des procédures de développement distinctes peuvent être développées séparément du reste de l’application. Dans les grandes entreprises, cela peut fournir un moyen d’exploiter davantage les compétences des programmeurs hautement spécialisés. En d’autres termes, les programmeurs d’applications peuvent écrire du code d’interface utilisateur et des programmeurs de base de données peuvent écrire des procédures.
Les procédures sont généralement utilisées par les applications verticales et personnalisées. Ces applications ont tendance à effectuer des tâches fixes et il est possible d’effectuer des appels de procédure en dur. Par exemple, une application d’entrée de commande peut appeler les procédures InsertOrder, DeleteOrder, UpdateOrder et GetOrders.
Il existe peu de raisons d’appeler des procédures à partir d’applications génériques. Les procédures sont généralement écrites pour effectuer une tâche dans le contexte d’une application particulière et n’ont donc aucune utilisation pour les applications génériques. Par exemple, une feuille de calcul n’a aucune raison d’appeler la procédure InsertOrder juste mentionnée. En outre, les applications génériques ne doivent pas construire de procédures au moment de l’exécution dans l’espoir de fournir une exécution plus rapide des instructions ; non seulement cela risque d’être plus lent que l’exécution directe ou préparée, il nécessite également des instructions SQL spécifiques au SGBD.
Il s’agit d’une exception pour les environnements de développement d’applications, qui permettent souvent aux programmeurs de créer des instructions SQL qui exécutent des procédures et qui peuvent permettre aux programmeurs de tester des procédures. De tels environnements appellent SQLProcedures pour répertorier les procédures disponibles et SQLProcedureColumns pour répertorier les paramètres d’entrée, d’entrée/sortie et de sortie, la valeur de retour de la procédure et les colonnes des jeux de résultats créés par une procédure. Toutefois, ces procédures doivent être développées au préalable sur chaque source de données ; cela nécessite des instructions SQL spécifiques au SGBD.
Il existe trois inconvénients majeurs à l’utilisation de procédures. La première est que les procédures doivent être écrites et compilées pour chaque SGBD avec laquelle l’application doit s’exécuter. Bien qu’il ne s’agit pas d’un problème pour les applications personnalisées, il peut augmenter considérablement le temps de développement et de maintenance des applications verticales conçues pour s’exécuter avec un certain nombre de SGBD.
Le deuxième inconvénient est que de nombreux SGBD ne prennent pas en charge les procédures. Là encore, il s’agit probablement d’un problème pour les applications verticales conçues pour s’exécuter avec un certain nombre de SGBD. Pour déterminer si les procédures sont prises en charge, une application appelle SQLGetInfo avec l’option SQL_PROCEDURES.
Le troisième inconvénient, particulièrement applicable aux environnements de développement d’applications, est que ODBC ne définit pas de grammaire standard pour la création de procédures. Autrement dit, bien que les applications puissent appeler des procédures interopérables, elles ne peuvent pas les créer de manière interopérable.