Version imprimable
Bonjour à tous :)
voilà, je suis sur une application .Net + C# + Oracle
j'voulais savoir quel est l'interêt d'utiliser les procédures stockées pour la gestion des données d'une bd plutôt que les requêtes sql ordinaires (pour l'insertion des données par exemple),
autrement dis est ce que ça aide à augmenter les performances de mon application?
merci à vous d'avance ;)
en soit les performances je dirais que non,
si tu as une requête à executer c'est autant correcte de l'écrire dans le code de ton appli, que de passer par une procédure stockée ( Sauf que dans le 2ême cas tu n'auras pas d'exception levées en cas d'erreur sql)
Par contre si ta requête varie, des champs différents à insérer, des tables impactées selon des conditions définies dans ton application,
la procédure stockées ne t'avantagera pas beaucoup sauf si tu décides de lui fournir ce qui change en variable envoyée par ton appli comme paramètre déclarés dans ta procédure.
On en utilise vraiment beaucoup pour notre site,
notamment parce que tu peux lancer à l'intérieur , des vues que tu auras créer au préalable
Je croyais que les procédures stockées permettait d'économiser au serveur l'interprétation de la requête car elle est précompilée.Citation:
en soit les performances je dirais que non,
Elle permettent également d'échanger moins d'informations entre le serveur et le client, non ?
nb : Sinon les procédure stockées ont un apport point de vue sécurité aussi je crois, car les utilisateurs n'accèdent pas directement aux tables
merci,
en faite, le truc c'est que mon appli doit permettre la recherche de données selon beaucoup de critères, donc j'ai pensé qu'une procédure stockée fera mieux l'affaire,
en plus, je ne sais pas si on peut déclarer toutes les requêtes nécessaires à une table ds le mm fichier comme c'est le cas pr les procédures, (pour des raisons de clareté :mouarf: )
mai bon, si ça n'a pas d'avantage et que ça ne me permettera pas de gérer les exeptions, mieux vaut utiliser les requêtes simples, n'est ce pas? :?
C'était juste une remarque sur ce que je sais (à mon niveau) des procédures stockées... Après il va falloir attendre des commentaires plus avisés que le mien sur le sujet pour confirmer ce que tu viens de dire ;)
merci pour les détails :king:
Citation:
Envoyé par binoo
c'est ce que je me suis dite au début, mais puisque c'est la première fois que je travaille sur ce genre de projet donc, j'veu avoir des détails de ce genre pour pouvoir choisir la meilleure solution pr mon appli :)
vos avis m'interessent et je veux en savoir plus si vous voulez bien :lol:
si après le deployement tu te rends compte d'une erreur (un champ supplémentaire a selectionner) tu peux modifier ta procedure mais si c'est une requete.......
Hardcode jamais du SQL dans ton application. C'est un tres mauvais design. Utilise les StoredProc à la place. Ton sql est tjrs à la meme place et c'est beaucoup mieux pour les changement. Car tu n'as pas a recompiler et réinstaller a chaque fois que tu veux faire un petit changement coté SQL.
+1 avec ca ;)Citation:
Envoyé par shwin
En plus de l'aspect pratique (centralisation des requetes sur le serveur sql), il y a également l'aspect sécurité qui n'est pas négligeable. Dans le cas d'une requete codé en dure (sans utiliser les paramètres) tu t'exposes à des risques de SQL Injection. Par exemple, tu as une table User dans laquelle tu stockes le users et mot de passe cripté.
Dans ton code tu vas écrire un truc du genre
string maReq = "select encryptedPassword from User where username='" + monUser + "'";
Côté client le user est rempli par un textbox.
Si un petit malin s'amuse à taper comme user : "toto;Drop table User;" ... et ben c'est le désastre :aie:
Il me semble, par contre, qu'il y a quelques protections coté Framework ASP.NET pour ça ... mais bon!
En plus, il y a quand mm l'aspect performance qui n'est pas à négliger dans le cas d'une "grosse requete".
Merci beaucoup à vous tous et sorry pr le retard :lol:
je comprend que les storedproc soient mieux sur plusieurs plans,
mais je crois que la manipulation des données doit se faire au niveau de la couche métier, alors si j'utilise les storedproc comment je peu respecter cet aspect là?
:)
Peut importe la façon dont tu fais. Dans le cas d'un développement 3-Tiers, il y a forcémment un moment ou dans ta couche métier tu vas appeler la couche données pour sauvegarder tes objets métiers.Citation:
Envoyé par foffffa
Pour ma part, ce que j'ai rencontré le plus souvent c'est des objets métiers qui possédaient des méthodes Save() Update() Delete() qui elles-mêmes appelaient la couche de données.
d'accord,
et est ce que vous pouvez me dire si je dois mettre le code des storedproc à la place de celui des requêtes, ou est ce que ça doi etre ailleurs psque à ce que j'ai vu VS ne prend pas de fichier .sql
Oui, tu n'auras qu'a utiliser une commande de type StoredProcedure, appeler ta procédure stockée et également donner les paramètres que prend ta procédure.
Enfin recherche "StoredProcedure Oracle c#". Tu devrais trouver ce qu'il faut ;)
Il ya plusieurs raisons à utiliser les "Stored Procedure" plutot que des requetes directement dans le code. (c'est meme d'ailleurs ce qui fait que je ne suis pas convaincut par LinqtoSql)
En voici quelques unes :
- Facilité de développement... correction. Si tu modifie la structure de ta base pour une raison X ou Y mais que cela ne remet pas en cause ton application, l'usage de requetes en dure, t'oblige à modifier ton applicatif et la recompiler et redéployer, les procédures stockées, il suffit de modifier leur code.
- Séparer les responsabilités... si un problème est inhérent aux données traitées par le programme, tu saura tout de suite quelle procédure est consernée, et quoi faire, dans du code "spaghetti", c'est beaucoup moins évident. De plus ainsi on sais qui a fait quoi, et l'innocent peu plus être accusé à la place du coupable.
- Rapidité d'exécution (1)... une procédure stockée est compilée au moment ou tu la créé. Dans la mesure ou elle est compilée elle est forcément plus rapide qu'une requête et même qu'une requête "préparée". La requete préparée est la réponse douteuses des pro-code spaghetti aux bons design, cependant la requete préparée nécessite de préparer la requête, donc cela est fait juste après l'avoir edité, le temps de préparation est parfois à prendre en compte.
(cette technique n'a d'intéret que sur les SGBD qui ne supporte pas les procédures stockées)
- Rapidité d'exécution (2) & Traffic réseau... Lorsque pour une tâche particulière, tu ne te contente pas de faire une seule lecture, ou une seule écriture pour une donnée particulière, mais tout un traitement sur plusieurs tables, tu sera obligé en temps normal de passer par plusieurs requêtes tu va donc les exécuter l'une après l'autre (traffic réseau parasite + lenteur) avec une procédure stockée tu fait un appel et c'est tout.
- Déléguation de tâches... pourquoi confier à une application le travail de SQL et vice versa. La manipulation de données, c'est typiquement la raison d'exister d'un SGBD, aussi pourquoi faire 15 requetes quand une procédure suffirait ? La procédure est exécutée coté SQL, donc toutes les requetes et le code qui les assemble entre elle est exécuté coté SQL, là ou il doit etre, si tu programme "old school", ton applicatif va faire des liaisons, manipulations qui sont normallement le travail de SQL... ton appli va perdre du temps, car elle sera souvent moins efficace que SQL pour ces traitements, et meme en multithread, pendant que ton appli fait ca, elle laisse pas de temps aux autres threads pour faire autre chose...
Particularité spécifique à SQL Server et Sybase ... Le SGBD après avoir remis sous forme d'arithmétique relationnelle toute requete, va optimiser cette requête en la réordonnant, ainsi une fois décomposée, les différentes opérations peuvent être exécuté dans un ordre précis visant a diminuer le traffic, la mémoire, et le temps. Le temps d'optimisation n'est pas gratuit.
Si tu prend chaque requete séparément, il va les optimiser l'une après l'autre à chaque fois qu'il les rencontre, une seule fois si tu les prépare, mais c'est au moment ou tu la prépare... une requete préparée ne l'est que pour le lot en cours.
Si tu programme en proc stocks, et que tu pose plusieurs requetes successives qu'il peut après passage en algebre relationnelle assembler pour obtenir un tout plus rapide, il le fera, et ce pendant la détermination de la forme compilée et du plan d'exécution.
Inconvénients liés aux procédures stockées :
Souvent on souhaite faire des insertions par lots... des insertions de type batchs, en particulier dans des univers type ETL (Extract, Transform & Load)
on va donc vouloir insérer plusieurs entrée en une seule fois. Bien que cela soit possible avec une procédure stockée car on peut préparer une procédure stockée, cela restera moins pratique à manipuler qu'une requête SQL simple, et les temps d'exécution s'en ferons ressentir pendant ces phases.
Cet inconvénient peut toutefois être "levé" partiellement en créant une procédure stockée qui fera ces insertions par lots, en recevant non pas une table, mais un descripteur XML.
Les SQBD qui supportent le XML et propose un moteur de XQuery permettrons à cette procédure de faire ce traitement, et les temps serons plus rapides que l'exécution de N fois la procédure si N est très grand.
SQL Server 2005 gère le Xml, quelque soit l'édition. Pour Oracle... (comme d'habitude, dépend de la version de l'édition...)
Je trouve le débat requête SQL/procédure stockée comparable à un débat L4G/L3G.
C'est très intéressant de voir que l'on réduit ainsi la puissance L4G à un simple appel L3G !
Pourtant les raisons sont bonnes et pragmatiques. Enfin, pas toujours, parce que l'on ne prend pas toujours soin de classer les raisons entre celles qui vont intéresser le développeur et celles qui vont influencer les performances.
Passer systématiquement par une procédure stockée revient à créer une couche intermédiaire obligatoire et donc consommatrice à l'exécution. Les applications d'aujourd'hui grouillent de ces petits riens que tout le monde dit indispensables et qui gaspillent temps et ressources (50% de bruit ? 80% de bruit ?).
Par contre, quand on programme une procédure stockée, on peut écrire du code plus efficace que la requête SQL équivalente car l'optimiseur du SGBD, chargé d'exécuter la requête, fait ce qu'il peut pour trouver dans quel sens faire le traitement.
Sinon, une procédure stockée n'a pas, simplement, la faculté de retourner plusieurs lignes contrairement à une requête SQL !!!!
Ma philosophie est qu'il ne faut pas tomber dans un nivellement systématique par le bas sous prétexte de respecter tout ce que disent les érudits.
Bonjour tout le monde,
merci beaucoup à vous,
vos explications sont vraiment très riches, et ça m'aide beaucoup :)
enfin de compte, je crois que la majorité des avis penchent vers les procs stockées, bon je crois qu'il ya de quoi :D
mais je croyais qu'une storedproc peut retourner plusieurs lignes, non?
bien entendu une proc stock peut retourner 1 ou plusieurs resultset...
aussi bien qu'une fonction stockée de type table.
la différence réside dans les conditions d'utilisations qui sont assez différentes et des contraintes de chacunes d'elles.
une fonction stockée ne peut pas appeler une procédure stockée.
elle ne peut appeler d'autres Fonctions stockée que dans le cadre d'un select...
la procédure stockée elle peut appeler une autre procédure stockée, créer du code SQL puis l'évaluer ...
une procédure stockée peut avoir des paramètres avec valeur par défaut, dans ce cas il n'est pas nécessaire de les fournir lors de l'appel.
une fonction stockée à le droit a avoir des paramètres avec valeur par défaut, mais cela n'a strictement aucun sens, car TOUS les paramètres doivent être fourni au moment de l'appel sauf si on la considère et exécute comme une vulgaire procédure stockée. (EXECUTE)
quand au nivellement par le bas... je suis circonspet...
je regrette que tant de developpeurs persistes à mettre leur requetes en dur dans leur code et que l'on passer des heures à s'arracher la tete à trouver qui fait quoi, pour des choses inutiles...
quand tu fait une requete puis un while sur les infos collectées juse avant dans ton code pour faire une seconde requete ... je trouve cela plutot ridicule, deja soit la requete aurait pu etre écrite avec des jointures ou dans un autre cas... meme si l'écriture en proc stock nécessiterais l'usage d'un "curseur" l'impacte en terme de performance mais surtout charge réseau PARASITE est souvent non négligeable.
que le petit développeur du dimanche qui code un ptit programme pour lui meme, dans son coin procéde de la sorte... c'est "normal", rien dans ce cas ne nécessite l'usage d'une procédure stockée,
mais qu'un "professionnel" (parfois j'en doute) se permette cela... dans un client lourd... je trouve cela assez pathétique, d'autant que 99% des dits développeurs oublies d'utiliser les transactions, et on obtient des choses assez fantastiques dans un environnement concurrentiel.
attention toutefois, les proc stock nécessitent parfois un peu plus de brainstorming... en effet dans la mesure ou elles sont exécuté sous forme d'un lot SQL, elles sont par essence des transactions à elles seules, aussi se fonctionnement peut t'il engendrer des soucis de deadlocks si on y prend pas garde.
merci cinemania, votre explication est vraiment très précise et convaincante :king:
ça m'aide énormement à mieux comprendre,
mais pour ce qu'a dis alain.couthures
[QUOTE=alain.couthures;3043938]Passer systématiquement par une procédure stockée revient à créer une couche intermédiaire obligatoire et donc consommatrice à l'exécution. QUOTE]
je croyais que les procédures stockées se situent au niveau de la couche de données, donc leur utilisation n'engendre pas la création d'une autre couche dans mon appli!!
mais dans ce cas les quelques points qui restent un peu flous pour moi c'est que après un mapping o/r, la couche DA (avec les méthodes CRUD + find) aura à communiquer avec les objets créés, dans ce cas les storedprocs se situent où au juste? parceque si la couche du mapping aura affaire aux tables et la couche DA aux procs on sera un peu sorti de l'approche par couches
et encore, quelle sera l'interet de la couche DA si la couche BL peut tt simplement appler mes storedprocs? bon à part le respect du développement en couches bien sûr :mouarf:
Dès qu'une requête complexe peut être appelée dans différentes situations, avec différents paramètres, le programmeur est content de faire une fonction ou une procédure stockée pour regrouper cela en un seul et même endroit. Comme un L4G est plus riche conceptuellement qu'un L3G, la dite fonction ou procédure sera retrouvera généralement avec plein de paramètres pas toujours présents et plein de tests pour voir lesquels sont là ou pas à l'exécution : le programmeur est fier de lui car il fait de l'informatique compliquée !
Si un nouveau besoin apparaît, pas d'hésitation : le programmeur rajoute une couche de fonction de plus pour ne pas perturber le code existant. On se retrouve avec une fonction à n+1 paramètres appelée par d'autres fonctions du même nom à n, ou moins, paramètres.
Pour satisfaire à la condition d'indépendance, il n'y a qu'un pas vite effectué pour qu'une procédure stockée ne soit pas appelée directement mais par l'intermédiaire de fonctions d'interface !
N'oublions pas que, parce que le compilateur ne peut pas comprendre la finalité d'un programme, il ne peut pas tout optimiser...
Selon la méthode "ceinture et bretelles", le code de la fonction ou de la procédure va peut-être aussi comporter la fameuse vérification de la validité des paramètres... Est-ce vraiment utile quand ces paramètres sont calculés ou quand ils ont déjà été vérifiés en amont ?
Si on dispose d'un environnement d'exécution n-tiers, personne ne fait confiance à l'autre (je n'ai, pourtant, jamais vu un "2" se transformer en "3" en passant d'un serveur à un autre...) et tous les éléments ont chacun plus de travail encore.
J'ai envie de dire "Arrêtons le gâchis !"... Une proportion énorme de lignes de code est là pour aider le programmeur sans avoir de valeur fonctionnelle effective. Comme la puissance des machines va en croissant, on ne voit pas souvent à quel point on gaspille de plus en plus et tout le monde est trop fier d'être si intelligent...
Bon, d'accord, mais que faire pour changer ça ? Il faut mieux gérer son code. Et, là, les éditeurs ne nous aident pas (pas encore...) à faire cela. Je pense que la solution est dans de la génération de code (une sorte de précompilation évoluée) chargée de mettre le code nécessaire et suffisant (dans le cas de cette discussion, une requête plutôt qu'un appel à une procédure stockée). C'est clair qu'on n'en est pas là aujourd'hui et la syntaxe des langages qui n'a pas évoluée depuis les années 70 ne facilite pas trop cela... mais on peut leur associer une notation XML et, là, un programme n'est plus qu'une donnée comme une autre et il devient transformable !!!
Je t'assure, on ne peut pas tout faire sous SQL.Citation:
Envoyé par shwin
Perso j'ai des requetes dynamiques très complexe qui ne pourraient jamais être performantes si elles étaient faites sous SQL.
Bien sur, on parle d'application un peu plus grande que la gestion du stock d'un magasin (le genre de projet ou les "design" peuvent être respecté à 100%).
Perso, j'ai une dll consacrée à l'accès aux données.
J'utilise les procs stockées pour Insertion/Modification et quelques selections complexes (appel de plusieurs requètes) pour des raisons de perfomances.
Les SELECT "simples" (une seule requete) sont effectués au niveau du code.
http://weblogs.asp.net/fbouma/archiv...tle_2100_.aspx
Dont en particulier http://weblogs.asp.net/fbouma/archiv.../18/38178.aspx et http://www.theserverside.net/news/th...d=31953#158113
Très vieux débat, c'est peut-être pas la peine de ressortir tous les arguments dans les deux sens :)
Et tous les arguments ne vont pas dans le sens des procédures stockées, loin de là, et c'est tant mieux.