Vous avez raison, il serait prudent de passer un nombre entier de cette façon. Cependant, il y a aussi un autre aspect de l'histoire.
Bien qu'il puisse être considéré comme sûr de mettre en forme un entier et de créer l'expression SQL, il existe également une considération de performance. Lorsque le serveur SQL voit une requête pour la première fois, il crée et met en cache le plan d'exécution de cette requête. La prochaine fois que la même requête est émise, le plan d'exécution sera réutilisé.
Si vous passez des chaînes différentes, elles seront considérées comme des requêtes distinctes, nécessitant des plans d'exécution distincts. Si vous transmettez la même requête paramétrée à chaque fois (avec des paramètres différents), le premier plan d'exécution sera réutilisé par SQL Server.
Même si vous ne vous souciez pas de l'avantage de performances, j'utiliserais toujours une requête paramétrée pour toutes les requêtes sur la base de données, même pour celles qui peuvent être considérées comme "sûres" comme vous l'avez fait remarquer. la façon dont l'application accède aux données. Si vous utilisez utilisez la requête paramétrée, cela vous évite également de déterminer si la requête est sûre à chaque fois afin de décider de quelle manière interroger la base de données.
+1 - L'avantage des performances résultant du paramétrage correct des requêtes signifie qu'il n'est pas très logique de ne PAS les paramétrer, jamais. Le paramétrage n'est pas seulement pour la prévention de l'injection SQL. –
+1 - le modèle cohérent consiste à utiliser des arguments de liaison. nous le faisons même dans le cas «sûr» d'un entier unique, parce que cela suit le même schéma que nous suivons dans des cas plus complexes. (l'analyse stricte d'une instruction unique n'aura pas beaucoup d'impact sur la performance d'une seule instruction, ce sont les milliers d'analyses par seconde qui ont un impact sur l'extensibilité) – spencer7593