Inline SQL par rapport à la procédure stockée

J'ai une simple SELECT avec quelques colonnes référencées dans la clause WHERE . Normalement, je fais ces simples dans le code VB (configurer un object Command, définir le type de command en text, définir le text de command à l'instruction Select). Cependant, je vois des problèmes de timeout. Nous avons optimisé à peu près tout ce que nous pouvons avec nos tables, etc.

Je me demandais s'il y aurait un gros impact sur les performances juste parce que je fais la requête de cette façon, par rapport à la création d'une simple procédure stockée avec quelques parameters. Je pense peut-être que le code inline force SQL à faire de la compilation supplémentaire, en créant un plan de requête, etc. qui ne se produirait pas si j'utilisais une procédure stockée.

Un exemple du SQL en cours d'exécution:

 SELECT TOP 1 * FROM MyTable WHERE Field1 = @Field1 ORDER BY ID DESC

Une requête SQL "inline" ou "ad-hoc" bien formée – si elle est correctement utilisée avec des parameters – est aussi bonne qu'une procédure stockée.

Mais c'est absolument crucial : vous devez utiliser des requêtes correctement paramétrées! Si vous ne le faites pas – si vous concaténez set votre SQL pour chaque requête – alors vous ne bénéficiez pas de ces points …

Tout comme avec une procédure stockée, lors de la première exécution, un plan d'exécution de requête doit être trouvé – puis ce plan d'exécution est mis en cache dans le cache du plan – exactement comme avec une procédure stockée.

Ce plan de requête est réutilisé encore et encore, si vous appelez votre instruction SQL paramétrée en ligne plusieurs fois – et que le plan de requête SQL "inline" est soumis aux mêmes politiques d'éviction de cache que le plan d'exécution d'une procédure stockée.

Juste de ce sharepoint vue – si vous utilisez vraiment des requêtes correctement paramétrées – il n'y a aucun avantage de performance pour une procédure stockée.

Les procédures stockées ont d'autres avantages (comme être une «frontière de security», etc.), mais la performance brute n'est pas l'un de leurs principaux points positifs.

Il est vrai que le db doit faire le travail supplémentaire que vous mentionnez, mais cela ne devrait pas donner lieu à un gros succès en termes de performances (sauf si vous exécutez la requête très, très fréquemment ..)

Utilisez sql profiler pour voir ce qui est réellement envoyé au server. Utilisez le moniteur d'activité pour voir si d'autres requêtes bloquent les vôtres.

Votre requête ne pourrait pas être plus simple. Field1 est-il indexé? Comme d'autres l'ont dit, il n'y a pas d'impact sur les performances associé aux requêtes "ad-hoc".

Pour savoir où poser vos questions, c'est l'un des débats les plus anciens de la technologie. Je dirais que vos requests "appartiennent" à votre request. Ils seront mis à jour avec votre application, testés avec votre application et devraient disparaître lorsque votre application disparaîtra. Les mettre n'importe où ailleurs que dans votre application marche dans un monde de douleur. Mais pour l'amour de Dieu, utilisez les files .sql, compilés en tant que ressources embeddedes.