Procédures stockées (moteur de base de données)

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) Base de données SQL dans Microsoft Fabric

Une procédure stockée dans SQL Server est un groupe d’une ou de plusieurs instructions Transact-SQL ou une référence à une méthode CLR (Common Runtime Language) Microsoft .NET Framework. Les procédures ressemblent à des constructions d'autres langages de programmation, car elles peuvent :

• accepter des paramètres d'entrée et retourner plusieurs valeurs sous la forme de paramètres de sortie au programme appelant ;

• contenir des instructions de programmation qui effectuent des opérations dans la base de données. Cela inclut l'appel d'autres procédures ;

• retourner une valeur d'état à un programme appelant pour indiquer une réussite ou un échec (et la raison de l'échec).

Avantages de l’utilisation des procédures stockées

La liste suivante décrit certains avantages de l'utilisation des procédures.

Trafic réseau serveur/client réduit

Les commandes d'une procédure sont exécutées comme un seul lot de codes. Cela peut réduire considérablement le trafic réseau entre le serveur et le client, car seul l'appel pour exécuter la procédure est envoyé sur le réseau. Sans encapsulation de code fournie par une procédure, chaque ligne de code individuelle doit être transmise sur le réseau.

Sécurité renforcée

Plusieurs utilisateurs et programmes clients peuvent effectuer des opérations sur les objets de base de données sous-jacents par le biais d’une procédure, même si les utilisateurs et les programmes n’ont pas d’autorisations directes sur ces objets sous-jacents. La procédure contrôle les processus et activités effectués et protège les objets de base de données sous-jacents. Cela élimine la nécessité d'accorder des autorisations au niveau de l'objet individuel et simplifie les couches de sécurité.

La clause EXECUTE AS peut être spécifiée dans l’instruction CREATE PROCEDURE pour permettre l’emprunt de l’identité d’un autre utilisateur, ou pour permettre aux utilisateurs ou aux applications d’effectuer certaines activités de base de données sans avoir besoin d’autorisations directes sur les commandes et les objets sous-jacents. Par exemple, il n’est pas possible d’accorder des autorisations à certaines actions, telles que TRUNCATE TABLE. Pour exécuter TRUNCATE TABLE, l’utilisateur doit disposer d’autorisations ALTER sur la table spécifiée. L’octroi à un utilisateur des autorisations ALTER sur une table est critiquable, car celui-ci disposera en réalité d’autorisations plus étendues que celles lui permettant de tronquer une table. En intégrant l’instruction TRUNCATE TABLE dans un module et en spécifiant que ce module s’exécute en tant qu’utilisateur disposant des autorisations de modifier la table, vous pouvez étendre les autorisations de tronquer la table à l’utilisateur auquel vous accordez les autorisations EXECUTE sur le module.

Lorsqu’une application appelle une procédure sur le réseau, seul l’appel pour exécuter la procédure est visible. Par conséquent, les utilisateurs malveillants ne peuvent pas voir les noms des objets de table et de base de données, incorporer leurs propres instructions Transact-SQL ou rechercher des données critiques.

L'utilisation des paramètres de procédure permet de se prémunir contre les attaques par injection de code SQL. Dans la mesure où l’entrée de paramètre est traitée comme une valeur littérale et non en tant que code exécutable, il est plus difficile à un intrus d’insérer une commande dans les instructions Transact-SQL de la procédure et de compromettre la sécurité.

Les procédures peuvent être chiffrées, ce qui permet d'obfusquer le code source. Pour plus d’informations, consultez Chiffrement de SQL Server.

Réutilisation du code

Le code de toute opération de base de données répétitive est le candidat parfait pour une encapsulation dans les procédures. Cela élimine les réécritures inutiles du même code, réduit les incohérences du code et permet l’accès et l’exécution du code par tout utilisateur ou toute application disposant des autorisations nécessaires.

Maintenance plus simple

Lorsque les applications clientes appellent des procédures et conservent les opérations de base de données dans la couche Données, seules les procédures doivent être mises à jour pour toutes les modifications apportées dans la base de données sous-jacente. La couche application reste distincte et peut ignorer les modifications apportées à la mise en page, aux relations et aux processus de base de données.

performances améliorées

Par défaut, une procédure est compilée à sa première exécution et crée un plan d’exécution qui est réutilisé pour les exécutions suivantes. Étant donné que le processeur de requêtes ne doit pas créer de plan, le traitement de la procédure dure généralement moins longtemps.

Si des modifications significatives ont été apportées aux tables ou aux données référencées par la procédure, le plan précompilé peut ralentir la procédure. Dans ce cas, la recompilation de la procédure et l'application forcée d'un nouveau plan d'exécution peuvent améliorer les performances.

Types de procédures stockées

Défini par l’utilisateur

Une procédure définie par l’utilisateur peut être créée dans une base de données définie par l’utilisateur ou dans toutes les bases de données système à l’exception de la base de données Resource. La procédure peut être développée dans Transact-SQL ou en tant que référence à une méthode CLR (Common Language Runtime) Microsoft .NET Framework.

Temporaire

Les procédures temporaires sont une forme de procédures définies par l'utilisateur. Les procédures temporaires sont comme une procédure permanente, sauf qu’elles sont stockées dans tempdb. Il en existe deux types : locale et globale. Elles se différencient par leur nom, leur visibilité et leur disponibilité. Le premier caractère du nom des procédures temporaires locales est un signe dièse (#) unique. Ces procédures sont visibles uniquement à la connexion actuelle de l’utilisateur et sont supprimées dès que la connexion est fermée. En revanche, le nom des procédures temporaires globales commence par deux signes dièse (##) ; ces procédures sont visibles à tout utilisateur après avoir été créées et sont supprimées à la fin de la dernière session qui utilise la procédure.

System

Les procédures système sont incluses avec le moteur de base de données. Elles sont stockées physiquement dans la base de données Resource masquée et interne, et elles apparaissent logiquement dans le schéma sys de chaque base de données définie par le système et définie par l’utilisateur. En outre, la base de données msdb contient également les procédures stockées système dans le schéma dbo, utilisées pour planifier les alertes et les travaux. Compte tenu du fait que les procédures système commencent par le préfixe sp_, nous vous recommandons de ne pas utiliser ce préfixe quand vous nommez des procédures définies par l’utilisateur. Pour obtenir la liste complète des procédures système, consultez Procédures stockées système (Transact-SQL).

SQL Server prend en charge les procédures système qui assurent l’interface entre SQL Server et les programmes externes pour diverses activités de maintenance. Ces procédures étendues utilisent le préfixe xp_. Pour obtenir la liste complète des procédures étendues, consultez Procédures stockées étendues générales (Transact-SQL).

Étendue définie par l’utilisateur

Les procédures étendues vous permettent de créer des routines externes dans un langage de programmation comme le langage C. Ce sont des DLL qu’une instance de SQL Server peut charger et exécuter dynamiquement.

Tâches associées

Contenu connexe

• Procédures stockées du CLR
• Résolution de noms différée