Les procédures stockées sont un lot d'instructions SQL qui peuvent être exécutées de plusieurs manières. La plupart des principaux DBM prennent en charge les procédures stockées; cependant, tous ne le font pas. Vous devrez vérifier avec la documentation d'aide de votre SGBD particulier pour plus de détails. Comme je connais mieux SQL Server, je l'utiliserai comme exemple.
Pour créer une procédure stockée la syntaxe est assez simple :
CREATE PROCEDURE <owner>.<procedure name>
<Param> <datatype>
AS
<Body>
Ainsi, par exemple :
CREATE PROCEDURE Users_GetUserInfo
@login nvarchar(30)=null
AS
SELECT * from [Users]
WHERE ISNULL(@login,login)=login
L'un des avantages des procédures stockées est que vous pouvez centraliser la logique d'accès aux données dans un emplacement unique, facile à optimiser pour les administrateurs de base de données. Les procédures stockées présentent également un avantage en matière de sécurité dans la mesure où vous pouvez accorder des droits d'exécution à une procédure stockée, mais l'utilisateur n'aura pas besoin d'autorisations de lecture/écriture sur les tables sous-jacentes. C'est un bon premier pas contre l'injection SQL.
Les procédures stockées présentent des inconvénients, essentiellement la maintenance associée à votre fonctionnement CRUD de base. Disons que pour chaque table vous avez une insertion, une mise à jour, une suppression et au moins une sélection basée sur la clé primaire, cela signifie que chaque table aura 4 procédures. Prenez maintenant une base de données de taille décente de 400 tables, et vous avez 1600 procédures ! Et cela en supposant que vous n'avez pas de doublons, ce que vous aurez probablement.
C'est là que l'utilisation d'un ORM ou d'une autre méthode pour générer automatiquement vos opérations CRUD de base a une tonne de mérites.
