Discussion :

[Bluedeep]

t'évite d'envoyer la requête vial le réseau ( donc plus performant).

Ouais, alors la on rentre un peu dans la tetrapilectomie(*), hein.

En effet il faudrait comparer la taille de la requête avec la taille de la requête d'exécution de la proc stoc.




(*) l'art de couper les cheveux en quatre.

[marcolo21]

Bonjour,

Désolé de réanimer cette belle conversation, mais j'aurai une question qui a raport avec ce que vous discuter depuit tout a l'heure.

Vous parler de mettre les requete dans des procedure stocké pour les requete de type insert,update et delete. Pour sa aucun problème.


Mais que faite vous avec les requête Select ?

Vous les placer elle aussi dans des procédure stocké ou vous faite autrement ?

merci

[Bluedeep]

Bonjour,

Mais que faite vous avec les requête Select ?

Vous les placer elle aussi dans des procédure stocké ou vous faite autrement ?

Il n'y a pas plus de problèmes à mettre un SELECT en proc stoc que toute autre commande SQL.

Donc, la réponse est oui, ça va dans les proc stoc.

[marcolo21]

Je ne sais pas si je comprend bien. Quand vous parler de mettreles requete dans des procédure stocké vous parler bien de les exécuté directement dans la procédure ? ou bien vous vouler dire que la procédure stocké renvois la requete.

Car si c'est le premier choix alors je ne comprend pas comment vous faite pour que sa marche avec un Select qui retourne plusieurs donné. Qu'est-ce que la procédure renvois dans ce cas.

merci

[Bluedeep]

Je ne sais pas si je comprend bien. Quand vous parler de mettreles requete dans des procédure stocké vous parler bien de les exécuté directement dans la procédure ?

Bien sur ! le cas contraire aurait peu d'interêt.

ou bien vous vouler dire que la procédure stocké renvois la requete.

Euh ... en général on est plus intéressé par le résultat que par la requête, non ?

Car si c'est le premier choix alors je ne comprend pas comment vous faite pour que sa marche avec un Select qui retourne plusieurs donné. Qu'est-ce que la procédure renvois dans ce cas.

Les données. C'est d'ailleurs ce qu'on lui demande.
Elle peut aussi avoir une valeur de retour (en plus), ainsi que des paramètres "output".

[marcolo21]

Désoler je vien de regarder de plus près les procédure stocké et je vien de me rendre compte qu'on peut lire les donné avec un reader comme si on l'aurai exécuté directement.

Sinon cette manière de faire est utile pour pas avoir a recompiler mais si les paramètre qu'on passe a la procedure change je parie qu'on va devoir recompliler le programme aussi.

Le seul problème que je vois a cette mannière de faire est le fait qu'il faut trouver des nom a nos procédure stocké et aussi que a la fin d'un gros programme il doit y avoir beaucoup de procédure stocké pour les requette dans la base ( je sais que c'est pas grave pour la taille, mais pour l'encombrement sa peut devenir perdu)

sinon dernière petite question. Qu'elle-est la difference entre une fonction et une procedure stocké en sql ?

merci

[Bluedeep]

Sinon cette manière de faire est utile pour pas avoir a recompiler mais si les paramètre qu'on passe a la procedure change je parie qu'on va devoir recompliler le programme aussi.

C'est un fait, mais ce n'est pas le cas le plus courant.

( je sais que c'est pas grave pour la taille, mais pour l'encombrement sa peut devenir perdu)

Comme pour les classes, les méthodes, les NS, etc .. : il faut adopter un schéma de nommage (de préférence au niveau corp. , ou, le cas échéant, au niveau projet) et s'y tenir.

sinon dernière petite question. Qu'elle-est la difference entre une fonction et une procedure stocké en sql ?

Les differences sont très nombreuses et on sort du cas d'une explication en quelques lignes.
Mais pour faire cours, une proc stoc peut faire "presque" tout ce que fait une fonction mais pas l'inverse. Les fonctions sont de plus limitées dans leur accès aux données. (de plus il y a trois types de fonctions, les "Table-valued Functions" ressemblant un peu et de loin aux proc stoc retournant une liste de données).

En revanche on peut mettre une fonction directement dans une requête

Exemple : (avec une fonction d'agrégat : pas d'équivalent en proc stoc)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select MyAggregateFunc(MyField1) from MyTable1

Ce qui est impossible avec une proc stoc.

A noter qu'avec Sql Server 2005 et + , les fonctions comme les proc stoc peuvent être aussi bien développées en C# qu'en T-SQL. (ce qui est ,parfois mais c'est rare, très pratique mais amène aussi certaines contraintes).

[Pol63]

Désolé je viens de regarder de plus près les procédure stocké et je vien de me rendre compte qu'on peut lire les donné avec un reader comme si on l'aurai exécuté directement.

oui c'est bien pratique oui, il suffit que la SP se termine par un select, et on peut par exemple faire des insert dans une table # puis faire le select

Sinon cette manière de faire est utile pour pas avoir a recompiler mais si les paramètre qu'on passe a la procedure change je parie qu'on va devoir recompliler le programme aussi.

oui

Le seul problème que je vois a cette mannière de faire est le fait qu'il faut trouver des nom a nos procédure stocké et aussi que a la fin d'un gros programme il doit y avoir beaucoup de procédure stocké pour les requette dans la base ( je sais que c'est pas grave pour la taille, mais pour l'encombrement sa peut devenir perdu)

trouver un nom à la procédure stocker c'est un avantage, au moins on sait ce que tu as voulu faire dans la procédure si tu la nommes CreateLivreur

après oui c'est dommage qu'sql server ne permette pas de créer des dossiers pour les ranger un peu, car dépassé la centaines ca fait de l'ascenseur à manipuler et il faut aiguiser les yeux

sinon dernière petite question. Qu'elle-est la difference entre une fonction et une procedure stocké en sql ?

comme en c# !
une procédure stockée c'est comme un void, ca exécute du code
et une fonction c'est comme une fonction, ca retourne quelque chose (une valeur pour les fonctions scalaires, une table pour les fonctions table)

edit j'ai été long à taper on dirait ^^

[Bluedeep]

comme en c# !
une procédure stockée c'est comme un void, ca exécute du code
et une fonction c'est comme une fonction, ca retourne quelque chose (une valeur pour les fonctions scalaires, une table pour les fonctions table)

Pas tout à fait : une proc stoc peut avoir un retour et des paramètres output.

Ce qu'on ne peut pas faire du tout en proc stoc c'est l'équivalent d'une fonction aggrégat.

Mais entre une fonction scalaire et une proc stoc ce qu'apporte la fonction c'est la possibilité d'être appelée dans une requête.

[Pol63]

Pas tout à fait : une proc stoc peut avoir un retour et des paramètres output.

une void de c# aussi avec déclaration dans l'appelant

[Bluedeep]

une void de c# aussi avec déclaration dans l'appelant

Bien sur mais pas de retour puisque il est "void", alors qu'une proc stoc peut avoir : données en retour + code retour + paramètres ouput tout cela à lafois.

J'admet que la phrase était ambigüe mais il est difficile de comparer des fonction/proc stoc SQL Server avec des méthodes pas void/void C# : les possibilités des fonctions en T-SQL sont clairement limitées dans ce qu'il est possible de faire à l'intérieur du code - et c'est valable aussi pour les fonctions Sql Server SQLCLR en C# (ou en VB.Net d'ailleurs) qui sont soumises aux même limitations.

[cinemania]

Pol63 a ta dernière remarque sur les plans d'exécution je n'ai rien à redire, et effectivement il faut bien toute une carrière pour le connaitre parfaitement ou alors se farcir tout le cursus de certifications associées à SQL Server

Comme il a été dit, autre intérêt de la procédure stockée, c'est qu'en plus d'un "resultset" elle peut retourner un code numérique, et elle peut retourner des valeurs par les paramètres output... ce qui est parfait pour cascader et remonter les erreurs.

La différence entre utiliser une procédure stockée et une requête au moment de le faire avec l'appli, se fait au niveau du plan d'exécution certes, mais au niveau de la notion de "batch"... une procédure stockée, comme une vue est TOUJOURS préparée, ce n'est pas le cas d'une requête par défaut, où il faudra l'envisager si on compte l'exécuter plusieurs fois d'affilée.
Sous Oracle il est nécessaire de forcer la "préparation", mais je ne sais plus s'il en est de même sur SQL Server 2008 R2... a vraie dire à force d'améliorer les produits, on fini par perdre le fil

[marcolo21]

MAis commes tous ce passe dirrectement sur sql server est-ce qu'on peut faire begintransaction en c# ou il faut faire les transaction (et les annuler si c'Est le cas) dirrectement sous sql server.


Sinon quelle son les autres moyen pour gardé des requête sql autre que dans des procédure stocké ? ( dans le cas ou je ne voudrai pas remplir toute mon dossier de procédure avec des centaines de procédure stocké pour mon programme)

[chamamo]

MAis commes tous ce passe dirrectement sur sql server est-ce qu'on peut faire begintransaction en c# ou il faut faire les transaction (et les annuler si c'Est le cas) dirrectement sous sql server.

c'est quoi l'intérêt?

Sinon quelle son les autres moyen pour gardé des requête sql autre que dans des procédure stocké ? ( dans le cas ou je ne voudrai pas remplir toute mon dossier de procédure avec des centaines de procédure stocké pour mon programme)

en quoi ça te gêne? ce dossier est fait pour stocker les proc stoc non?

[marcolo21]

c'est quoi l'intérêt?

L'intérêt est que si une requête ne marche pas j'annule tous les autres (RollBack) pour pas que la transaction passe et j'envoie un message d'erreur a l'usager.

[chamamo]

L'intérêt est que si une requête ne marche pas j'annule tous les autres (RollBack) pour pas que la transaction passe et j'envoie un message d'erreur a l'usager.

tu peux faire le rollBack dans ton application c#.

[marcolo21]

Donc je peux faire ca directement sous c# :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
transaction = connection.BeginTransaction();
 
Command.Transaction = transaction;
 
try
{
Command.ExecuteNonQuery(); // Execution de la procedure stocké
}
catch
{
transaction.RollBack();
}

et avec ce code la (il se peux qu'il y ai des erreur dans mon code je l'ai fait vite) toute les insert, update ou delete vont être annuler ?

merci

[chamamo]

Tout code SQL exécuté dans la connexion est concerné par la transaction, mémé les procédures stockées.

[marcolo21]

Merci beaucoup pour ta réponce sa répond a peut près a tous les intérogation que j'avais au niveau des procédure stocké

en quoi ça te gêne? ce dossier est fait pour stocker les proc stoc non?

Je sais qu'il est fait pour sa mais quand il est bien remplis sa devien brouillon. Si on pourai faire des dossier pour les classé sa serai génial mais on peut pas.
C'est pour sa que je demandais s'il y avait d'autre moyen pour envisager toute les solucion lors de mon prochain programme.

[chamamo]

Si on pourai faire des dossier pour les classé sa serai génial mais on peut pas.

un proc stoc explorer ^^

tu peux organiser tes proc stoc en utilisant des préfixes

évite le préfixe "sp_" (pour éviter un conflit s'il y aura une proc stoc system qui portera le même nom que la tienne)

et il est recommandé aussi de ne pas utilisé ce préfixe car SQL Server recherche toujours une procédure stockée commençant par sp_ dans l’ordre suivant :

1. elle existe dans la base de données master ;
2. ensuite, en fonction des éventuels identificateurs fournis (nom de base de données ou propriétaire) ;
3. enfin, avec dbo comme propriétaire si aucun propriétaire n’est spécifié.