Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Intérêt d'une procédure stocké...

Intérêt d'une procédure stocké...

21 réponses
Avatar
Sylo
Bonjour,

J'utilise une application asp.net interfacé avec une base de données
SqlServer.
J'aimerais savoir l'intérêt des procédures stockés par rapport au fait
d'utiliser simplement une chaine de caractère (contenant la requête)
utiliser pour interroger la base via ADO.NET
MErci
Sylo
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Fred BROUARD
c'est très simple :
façon la moins performante : chaine de car. représentant une requête à exécuter.
la plus performante : requête SQL encapsulé dans une proc stock.

En effet MS SQL Server utilise un cache pour toutes les données et pour toutes
les procédures. Cela signifie que lors d'une première exécution la procédure est
montée en mémoire et y reste même un fois le travail termeiné, au cas ou l'on
redemanderais la même, ce que bien évidemmetn il ne peut pas faire si c'est un
bout de chaine de caractères.
De plus les proc Stock sont précompilées, donc la plupart des informations
préalables à l'éxécution de la PS sont stockées avec.
Enfin, une PS peut encapsuler une multitude de requête et évite dons des aller
et retour réseau très pénalisant.

Si l'on veut des performances il faut utiliser UNIQUEMENT des proc stock.

Et contrairement à ce que l'on pense, les proc stock sont le seul moyen de faire
des applications opérables sur différents SGBDR sans quasiement aucun changement
du code client.

A +



Sylo a écrit:
Bonjour,

J'utilise une application asp.net interfacé avec une base de données
SqlServer.
J'aimerais savoir l'intérêt des procédures stockés par rapport au fait
d'utiliser simplement une chaine de caractère (contenant la requête)
utiliser pour interroger la base via ADO.NET
MErci
Sylo





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Ambassadeur Kosh
- le langage accepté par les SqlCommand ne couvre pas la totalité du Sql.
donc la StoreProc t'offre la possibilité de faire "tout ce qu'il est
possible de faire"
- on prete souvent aux store proc une vertu d'efficacité, en disant qu'elle
s'execute sur le server et qu'il n'y a pas de ping pong avec le client. moi
je dis à voir...
- la store proc peut s'apparenter à une classe abstraite et une
implantation. le jour ou tu bricoles ta BD en changeant un nom de champ par
exemple, tu changes la storeproc sans retoucher à l'appli. la, faut peser le
pour et le contre...

dans l'idée de 1 et de 3, j'ai vu certains definir la store-proc comme point
de passage unique vers la base, et concentrer la logique de COMIT / ROLLBACK
à l'interieur...

et certainement encore plein d'autres choses que j'ai oublié... voila voila
Avatar
Sylo
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier de
"script", sont trés rigides. Je m'explique. Si par exemple, je veux faire un
systeme de requète utilisateur ou l'utilisateur choisit les champs d'une
table qu'il veut se voir retourner par la requête (on ne sait donc pas les
champs à interroger au moment du codage de la requête), est-il possible de
faire cela avec une procédure stocké (en passant la liste des champs à
remonter via un paramètre) ?
MErci
Sylo

"Ambassadeur Kosh" a écrit dans le message de
news: 4pV0f.40925$
- le langage accepté par les SqlCommand ne couvre pas la totalité du Sql.
donc la StoreProc t'offre la possibilité de faire "tout ce qu'il est
possible de faire"
- on prete souvent aux store proc une vertu d'efficacité, en disant
qu'elle s'execute sur le server et qu'il n'y a pas de ping pong avec le
client. moi je dis à voir...
- la store proc peut s'apparenter à une classe abstraite et une
implantation. le jour ou tu bricoles ta BD en changeant un nom de champ
par exemple, tu changes la storeproc sans retoucher à l'appli. la, faut
peser le pour et le contre...

dans l'idée de 1 et de 3, j'ai vu certains definir la store-proc comme
point de passage unique vers la base, et concentrer la logique de COMIT /
ROLLBACK à l'interieur...

et certainement encore plein d'autres choses que j'ai oublié... voila
voila



Avatar
Zim
Sylo a écrit :
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier de
"script", sont trés rigides. Je m'explique. Si par exemple, je veux faire un
systeme de requète utilisateur ou l'utilisateur choisit les champs d'une
table qu'il veut se voir retourner par la requête (on ne sait donc pas les
champs à interroger au moment du codage de la requête), est-il possible de
faire cela avec une procédure stocké (en passant la liste des champs à
remonter via un paramètre) ?
MErci
Sylo



Non, il n'et pas possible de passer en paramètre les champs à retourner.
Mais ce n'est pas le rôle de SQL Server de gérer la partie
visualisation, amha, la procédre stockée renvoie toujours les mêmes
champs, et c'est à l'application cliente de proposer les "vues" en
fonction du besoin.

Zim.
Avatar
Sylo
Une autre problèmatique, c'est que les procédure stocké sont totalement
deconnecté du code. C'est en fait un fichier sur le serveur Sql. Il suffit
que l'on change une procédure et il faut changer tout le code qui utilise
cette procédure en courant aprés les ado.net qui utilise cette procédure
stocké. Il n'y aurait pas une manière plus simple de lier les procédures au
codes ???
Merci
Sylo

"Zim" <"r[omuald].szymanskiANTI"@SPAMlaposte.net> a écrit dans le message de
news:
Sylo a écrit :
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier
de "script", sont trés rigides. Je m'explique. Si par exemple, je veux
faire un systeme de requète utilisateur ou l'utilisateur choisit les
champs d'une table qu'il veut se voir retourner par la requête (on ne
sait donc pas les champs à interroger au moment du codage de la requête),
est-il possible de faire cela avec une procédure stocké (en passant la
liste des champs à remonter via un paramètre) ?
MErci
Sylo



Non, il n'et pas possible de passer en paramètre les champs à retourner.
Mais ce n'est pas le rôle de SQL Server de gérer la partie visualisation,
amha, la procédre stockée renvoie toujours les mêmes champs, et c'est à
l'application cliente de proposer les "vues" en fonction du besoin.

Zim.


Avatar
Thierry
Bien sûr que c'est possible de passer en paramètre la liste des champs à une
procédure stockée.
De plus, limiter la liste des colonnes retournées me semble important pour
limiter le volume de données transmis par Server Sql

Mais dans le cas cité par Sylo : requête composée dynamiquement par
l'utilisateur, je ne vois pas l'interêt d'une procédure stockée. Sauf peut
être une procédure temporaire générée à la volée.

Il ne faut pas être des intégristes : ce n'est parce que les procédures
stockées sont considérées en règle générale comme la meilleure technique,
qu'il ne faut faire que ça.

--
Thierry


"Zim" <"r[omuald].szymanskiANTI"@SPAMlaposte.net> a écrit dans le message de
news:
Sylo a écrit :
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier
de "script", sont trés rigides. Je m'explique. Si par exemple, je veux
faire un systeme de requète utilisateur ou l'utilisateur choisit les
champs d'une table qu'il veut se voir retourner par la requête (on ne
sait donc pas les champs à interroger au moment du codage de la requête),
est-il possible de faire cela avec une procédure stocké (en passant la
liste des champs à remonter via un paramètre) ?
MErci
Sylo



Non, il n'et pas possible de passer en paramètre les champs à retourner.
Mais ce n'est pas le rôle de SQL Server de gérer la partie visualisation,
amha, la procédre stockée renvoie toujours les mêmes champs, et c'est à
l'application cliente de proposer les "vues" en fonction du besoin.

Zim.


Avatar
Thierry
Celà devrait être effectivement le rôle de l'environnement de développement
de gèrer le code source des procédures stockés et de synchroniser
automatiquement la base de données (base de dév. d'abord) au moment de la
compilation du projet.

--
Thierry


"Sylo" <devbnet@[antispam]free.fr> a écrit dans le message de news:
%
Une autre problèmatique, c'est que les procédure stocké sont totalement
deconnecté du code. C'est en fait un fichier sur le serveur Sql. Il suffit
que l'on change une procédure et il faut changer tout le code qui utilise
cette procédure en courant aprés les ado.net qui utilise cette procédure
stocké. Il n'y aurait pas une manière plus simple de lier les procédures
au codes ???
Merci
Sylo

"Zim" <"r[omuald].szymanskiANTI"@SPAMlaposte.net> a écrit dans le message
de news:
Sylo a écrit :
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier
de "script", sont trés rigides. Je m'explique. Si par exemple, je veux
faire un systeme de requète utilisateur ou l'utilisateur choisit les
champs d'une table qu'il veut se voir retourner par la requête (on ne
sait donc pas les champs à interroger au moment du codage de la
requête), est-il possible de faire cela avec une procédure stocké (en
passant la liste des champs à remonter via un paramètre) ?
MErci
Sylo



Non, il n'et pas possible de passer en paramètre les champs à retourner.
Mais ce n'est pas le rôle de SQL Server de gérer la partie visualisation,
amha, la procédre stockée renvoie toujours les mêmes champs, et c'est à
l'application cliente de proposer les "vues" en fonction du besoin.

Zim.






Avatar
Ambassadeur Kosh
j'ai ecris un custom tool pour ça.
en gros, ça se lie à une base et ça genere les class pour chaque StoreProc
comme on le fait pour un Dataset.
et du coup, les changements ne passent pas inaperçus...

si ça t'interesse...
Avatar
Ambassadeur Kosh
> Il ne faut pas être des intégristes : ce n'est parce que les procédures
stockées sont considérées en règle générale comme la meilleure technique,
qu'il ne faut faire que ça.



oui, c'est le 4° point que j'ai omis de mentionner.

- la StoreProc soigne le cancer, reduit la fracture sociale, favorise le
retours à l'emplois, ameliore la vie des usagers de la RATP, et augmente les
revenus non imposable des utilisateurs.

plus serieusement, je serais curieux d'avoir quelques mesures et quelques
descriptions de contextes histoire de me faire une premiere idée sur l'ordre
de grandeur du gain entre SqlCommand inline et StoredProc. Les arguments de
fred sont indiscutables, mais, quand meme...

quand à l'execution des requetes multiples genre UPDATE ... ; SELECT ... ;
je n'ai pas d'idée précise de la façon dont c'est executé côté Dotnet. si
allez-et-retours reseau il y'a, mesure s'impose afin de savoir combien de
temps en proportion y est consacré dans chaque cas...
Avatar
Fred BROUARD
Contrairement a ce que te dit Zim, c'est parfaitement possible de le faire
puisque SQL Server permet de faire du SQL dynamique.

Autre affirmation farfelue :
"Il suffit
que l'on change une procédure et il faut changer tout le code qui utilise
cette procédure en courant aprés les ado.net qui utilise cette procédure
stocké. Il n'y aurait pas une manière plus simple de lier les procédures au
codes ???"
Mise à part si le nom ou les paramètres de la proc stock diverge il n'y a pas
lieu de changer quoi que ce soit !

En ce qui concerne les performances, c'est très simple. les gains mesurés sont
de l'ordre de 30 à 20 000 %. C'est notament vrai dans l'enchaînement de requêtes
qui nécessite des aller et retour réseau alors que ces derniers pourraît être
évité si le code est réalisé dans une SP. De plus la gestion de transaction côté
client est ce qu'il y a de pire pour bloquer une base de données.

Attention, ne pas faire dans une SP quelque chose qui n'a pas d'intérêt comme un
simple SELECT. Dans ce cas la "lourdeur" de la proc stock la fera moins
performante !

A +


Sylo a écrit:
Merci pour ces éclairages...
Alors voila mon problème.
J'ai le sentiment que les procédure stocké, du fait que c'est un fichier de
"script", sont trés rigides. Je m'explique. Si par exemple, je veux faire un
systeme de requète utilisateur ou l'utilisateur choisit les champs d'une
table qu'il veut se voir retourner par la requête (on ne sait donc pas les
champs à interroger au moment du codage de la requête), est-il possible de
faire cela avec une procédure stocké (en passant la liste des champs à
remonter via un paramètre) ?
MErci
Sylo

"Ambassadeur Kosh" a écrit dans le message de
news: 4pV0f.40925$

- le langage accepté par les SqlCommand ne couvre pas la totalité du Sql.
donc la StoreProc t'offre la possibilité de faire "tout ce qu'il est
possible de faire"
- on prete souvent aux store proc une vertu d'efficacité, en disant
qu'elle s'execute sur le server et qu'il n'y a pas de ping pong avec le
client. moi je dis à voir...
- la store proc peut s'apparenter à une classe abstraite et une
implantation. le jour ou tu bricoles ta BD en changeant un nom de champ
par exemple, tu changes la storeproc sans retoucher à l'appli. la, faut
peser le pour et le contre...

dans l'idée de 1 et de 3, j'ai vu certains definir la store-proc comme
point de passage unique vers la base, et concentrer la logique de COMIT /
ROLLBACK à l'interieur...

et certainement encore plein d'autres choses que j'ai oublié... voila
voila









--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
1 2 3