Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en
plusieurs petites et les appeller au fur et à mesure dans une, en gros faire
de la programmation modulaire comme en C ou au contraire vaut'il mieux faire
un "gros code" ?
Je me pose la question car je me demande si finallement je ne perds pas en
performance en découpant mes procédures en différents modules car je me
demande comment SQL Server pré compile les procédures dans ce cas .
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
Med Bouchenafa
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres. Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de performances. Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la taille des SP et améliorer leur lisibilité.
-- Bien cordialement Med Bouchenafa
"Alain" a écrit dans le message de news:
Bonjour,
Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en plusieurs petites et les appeller au fur et à mesure dans une, en gros faire de la programmation modulaire comme en C ou au contraire vaut'il mieux faire un "gros code" ?
Je me pose la question car je me demande si finallement je ne perds pas en performance en découpant mes procédures en différents modules car je me demande comment SQL Server pré compile les procédures dans ce cas .
Si quelqu'un à une réponse ou des liens,
merci d'avance
Alain
Chaque procédure est compilée à part.
Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de
travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres.
Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de
performances.
Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la
taille des SP et améliorer leur lisibilité.
--
Bien cordialement
Med Bouchenafa
"Alain" <abazoul@hotmail.com> a écrit dans le message de news:
uUQqKly9EHA.2608@TK2MSFTNGP10.phx.gbl...
Bonjour,
Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en
plusieurs petites et les appeller au fur et à mesure dans une, en gros faire
de la programmation modulaire comme en C ou au contraire vaut'il mieux faire
un "gros code" ?
Je me pose la question car je me demande si finallement je ne perds pas en
performance en découpant mes procédures en différents modules car je me
demande comment SQL Server pré compile les procédures dans ce cas .
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres. Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de performances. Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la taille des SP et améliorer leur lisibilité.
-- Bien cordialement Med Bouchenafa
"Alain" a écrit dans le message de news:
Bonjour,
Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en plusieurs petites et les appeller au fur et à mesure dans une, en gros faire de la programmation modulaire comme en C ou au contraire vaut'il mieux faire un "gros code" ?
Je me pose la question car je me demande si finallement je ne perds pas en performance en découpant mes procédures en différents modules car je me demande comment SQL Server pré compile les procédures dans ce cas .
Si quelqu'un à une réponse ou des liens,
merci d'avance
Alain
Alain
D'accord, donc si je comprends bien, il vaut mieux que MSSQL compile une seule procédure que plusieurs plus petites ? Merci pour ces précisions car je pensais complétement l'inverse !
Alain
"Med Bouchenafa" wrote in message news:
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une
sous-procédures pour éviter de
travailler avec un plan d'exécution mal adaptée à certains jeux de
paramètres.
Le fait de développer des SP à la "C" peut donc complètement changer la
donne en terme de
performances. Personnellement, je déconseille de travailler de la sorte. Il faut se
> plusieurs petites et les appeller au fur et à mesure dans une, en gros
faire
> de la programmation modulaire comme en C ou au contraire vaut'il mieux
faire
> un "gros code" ? > > Je me pose la question car je me demande si finallement je ne perds pas
en
> performance en découpant mes procédures en différents modules car je me > demande comment SQL Server pré compile les procédures dans ce cas . > > Si quelqu'un à une réponse ou des liens, > > merci d'avance > > Alain > >
D'accord, donc si je comprends bien, il vaut mieux que MSSQL compile une
seule procédure que plusieurs plus petites ?
Merci pour ces précisions car je pensais complétement l'inverse !
Alain
"Med Bouchenafa" <com.tetraset@Bouchenafa> wrote in message
news:OJDzYG19EHA.2032@tk2msftngp13.phx.gbl...
Chaque procédure est compilée à part.
Des fois, on fait même exprès de sortir un bout de code dans une
sous-procédures pour éviter de
travailler avec un plan d'exécution mal adaptée à certains jeux de
paramètres.
Le fait de développer des SP à la "C" peut donc complètement changer la
donne en terme de
performances.
Personnellement, je déconseille de travailler de la sorte. Il faut se
débrouiller pour limiter la
taille des SP et améliorer leur lisibilité.
--
Bien cordialement
Med Bouchenafa
"Alain" <abazoul@hotmail.com> a écrit dans le message de news:
uUQqKly9EHA.2608@TK2MSFTNGP10.phx.gbl...
> Bonjour,
>
> Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées
en
> plusieurs petites et les appeller au fur et à mesure dans une, en gros
faire
> de la programmation modulaire comme en C ou au contraire vaut'il mieux
faire
> un "gros code" ?
>
> Je me pose la question car je me demande si finallement je ne perds pas
en
> performance en découpant mes procédures en différents modules car je me
> demande comment SQL Server pré compile les procédures dans ce cas .
>
> Si quelqu'un à une réponse ou des liens,
>
> merci d'avance
>
> Alain
>
>
D'accord, donc si je comprends bien, il vaut mieux que MSSQL compile une seule procédure que plusieurs plus petites ? Merci pour ces précisions car je pensais complétement l'inverse !
Alain
"Med Bouchenafa" wrote in message news:
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une
sous-procédures pour éviter de
travailler avec un plan d'exécution mal adaptée à certains jeux de
paramètres.
Le fait de développer des SP à la "C" peut donc complètement changer la
donne en terme de
performances. Personnellement, je déconseille de travailler de la sorte. Il faut se
> plusieurs petites et les appeller au fur et à mesure dans une, en gros
faire
> de la programmation modulaire comme en C ou au contraire vaut'il mieux
faire
> un "gros code" ? > > Je me pose la question car je me demande si finallement je ne perds pas
en
> performance en découpant mes procédures en différents modules car je me > demande comment SQL Server pré compile les procédures dans ce cas . > > Si quelqu'un à une réponse ou des liens, > > merci d'avance > > Alain > >
David
Salut,
L'utilisation d'une procédure est prévérable. Mais peut on avoir une procédure qui gére l'ajout, la modification et la suppression sur une table. Et une autre requette ou l'on trouve toutes les possibilitées "Select" possible.
Et chaque parties est appellé selon les paramétres envoyés. Es ce que cela peut avoir une incidence sur les statistiques sur les SP.
Coordialement David
"Med Bouchenafa" wrote:
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres. Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de performances. Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la taille des SP et améliorer leur lisibilité.
-- Bien cordialement Med Bouchenafa
"Alain" a écrit dans le message de news:
> Bonjour, > > Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en > plusieurs petites et les appeller au fur et à mesure dans une, en gros faire > de la programmation modulaire comme en C ou au contraire vaut'il mieux faire > un "gros code" ? > > Je me pose la question car je me demande si finallement je ne perds pas en > performance en découpant mes procédures en différents modules car je me > demande comment SQL Server pré compile les procédures dans ce cas . > > Si quelqu'un à une réponse ou des liens, > > merci d'avance > > Alain > >
Salut,
L'utilisation d'une procédure est prévérable. Mais peut on avoir une
procédure qui gére l'ajout, la modification et la suppression sur une table.
Et une autre requette ou l'on trouve toutes les possibilitées "Select"
possible.
Et chaque parties est appellé selon les paramétres envoyés. Es ce que
cela peut avoir une incidence sur les statistiques sur les SP.
Coordialement David
"Med Bouchenafa" wrote:
Chaque procédure est compilée à part.
Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de
travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres.
Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de
performances.
Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la
taille des SP et améliorer leur lisibilité.
--
Bien cordialement
Med Bouchenafa
"Alain" <abazoul@hotmail.com> a écrit dans le message de news:
uUQqKly9EHA.2608@TK2MSFTNGP10.phx.gbl...
> Bonjour,
>
> Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en
> plusieurs petites et les appeller au fur et à mesure dans une, en gros faire
> de la programmation modulaire comme en C ou au contraire vaut'il mieux faire
> un "gros code" ?
>
> Je me pose la question car je me demande si finallement je ne perds pas en
> performance en découpant mes procédures en différents modules car je me
> demande comment SQL Server pré compile les procédures dans ce cas .
>
> Si quelqu'un à une réponse ou des liens,
>
> merci d'avance
>
> Alain
>
>
L'utilisation d'une procédure est prévérable. Mais peut on avoir une procédure qui gére l'ajout, la modification et la suppression sur une table. Et une autre requette ou l'on trouve toutes les possibilitées "Select" possible.
Et chaque parties est appellé selon les paramétres envoyés. Es ce que cela peut avoir une incidence sur les statistiques sur les SP.
Coordialement David
"Med Bouchenafa" wrote:
Chaque procédure est compilée à part. Des fois, on fait même exprès de sortir un bout de code dans une sous-procédures pour éviter de travailler avec un plan d'exécution mal adaptée à certains jeux de paramètres. Le fait de développer des SP à la "C" peut donc complètement changer la donne en terme de performances. Personnellement, je déconseille de travailler de la sorte. Il faut se débrouiller pour limiter la taille des SP et améliorer leur lisibilité.
-- Bien cordialement Med Bouchenafa
"Alain" a écrit dans le message de news:
> Bonjour, > > Est-ce quelqu'un sait s'il vaut mieux découper ses procédures stockées en > plusieurs petites et les appeller au fur et à mesure dans une, en gros faire > de la programmation modulaire comme en C ou au contraire vaut'il mieux faire > un "gros code" ? > > Je me pose la question car je me demande si finallement je ne perds pas en > performance en découpant mes procédures en différents modules car je me > demande comment SQL Server pré compile les procédures dans ce cas . > > Si quelqu'un à une réponse ou des liens, > > merci d'avance > > Alain > >
