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 ***********************
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" <kosh.naranek@babylon5.net> a écrit dans le message de
news: 4pV0f.40925$hV3.19610@nntpserver.swip.net...
- 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 ***********************
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 ***********************
Une application cliente peut toujours envoyer un script complexe au serveur
qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de performances
sera moins de 30% dans la plupart des cas.
Une application cliente peut toujours envoyer un script complexe au serveur
qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de performances
sera moins de 30% dans la plupart des cas.
Une application cliente peut toujours envoyer un script complexe au serveur
qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de performances
sera moins de 30% dans la plupart des cas.
Thierry a écrit:Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
Thierry a écrit:
Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
Thierry a écrit:Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
Thierry a écrit:Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
Thierry a écrit:
Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
Thierry a écrit:Une application cliente peut toujours envoyer un script complexe au
serveur qui sera executé comme un seul lot. (1 seul aller/retour)
Décider d'en faire une procédure stockée, c'est seulement décider de
l'enregistrer définitivement sur le serveur. La diffèrence de
performances sera moins de 30% dans la plupart des cas.
Tu oublie le cache de procédure !!!!
Pour un "one shot" tu as raison. Pour de multiples exec, c'est autre
chose...
A +
--
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 ***********************
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
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
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
Il y a également un cache des commandes SQL très efficace dans SQL Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement la
procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de voir
si SQL Server a utilisé un plan exécution déjà présent dans son cache, pour
executer une commande.
Il y a également un cache des commandes SQL très efficace dans SQL Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement la
procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de voir
si SQL Server a utilisé un plan exécution déjà présent dans son cache, pour
executer une commande.
Il y a également un cache des commandes SQL très efficace dans SQL Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement la
procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de voir
si SQL Server a utilisé un plan exécution déjà présent dans son cache, pour
executer une commande.
Bonjour,
2. Cacher la complexité de la base à l'application (c'est à mon avis le
point le plus important), exemple classique (et fictif):
Une table est constituée ainsi :
Create table COMMENTAIRES (Id int PRIMARY KEY, Commentaire1 nvarchar(1000),
Commentaire2 nvarchar(1000), Commentaire3 nvarchar(1000))
Une application quelconque affiche dans un datagrid le contenu de la table
commentaires.
1er cas : l'appli envoie un select * from COMMENTAIRES
2ème cas : l'appli appelle une procédure sp_GetCommentaires qui renvoie le
même select * from COMMENTAIRES
Les utilisateurs souhaitent obtenir une 4ème colonne de commentaire qui soit
également un nvarchar(1000):
d'un point de vue modelisation dans sql server on ne peut décemment pas
ajouter cette colonne dans la table commentaires car avec cette nouvelle
colonne on dépasserait la limite des 8000 octets gérables dans une ligne de
table. On s'exposerait à de la perte de données utilisateurs.
Donc on crée une 2ème table:
Create table COMMENTAIRES_EXTRA (Id int PRIMARY KEY, Commentaire4
nvarchar(1000))
L'importance de la procédure stockée apparait maintenant:
1er cas:
il faut modifier son appli pour remplacer sa requête par select * from
COMMENTAIRES c1 inner join COMMENTAIRES_EXTRA c2 on c1.Id = c2.Id
il faut recompiler l'appli
il faut redéployer l'appli aux utilisateurs
2ème cas:
on remplace la requête dans la procédure sp_GetCommentaires et l'appli
n'y voit que du feu!!!
Ok dans la vraie vie je ne gére pas les commentaires de cette manière mais
l'exemple est très parlant... je pense.
bonne soirée.
"Sylo" <devbnet@[antispam]free.fr> wrote in message
news: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
Bonjour,
2. Cacher la complexité de la base à l'application (c'est à mon avis le
point le plus important), exemple classique (et fictif):
Une table est constituée ainsi :
Create table COMMENTAIRES (Id int PRIMARY KEY, Commentaire1 nvarchar(1000),
Commentaire2 nvarchar(1000), Commentaire3 nvarchar(1000))
Une application quelconque affiche dans un datagrid le contenu de la table
commentaires.
1er cas : l'appli envoie un select * from COMMENTAIRES
2ème cas : l'appli appelle une procédure sp_GetCommentaires qui renvoie le
même select * from COMMENTAIRES
Les utilisateurs souhaitent obtenir une 4ème colonne de commentaire qui soit
également un nvarchar(1000):
d'un point de vue modelisation dans sql server on ne peut décemment pas
ajouter cette colonne dans la table commentaires car avec cette nouvelle
colonne on dépasserait la limite des 8000 octets gérables dans une ligne de
table. On s'exposerait à de la perte de données utilisateurs.
Donc on crée une 2ème table:
Create table COMMENTAIRES_EXTRA (Id int PRIMARY KEY, Commentaire4
nvarchar(1000))
L'importance de la procédure stockée apparait maintenant:
1er cas:
il faut modifier son appli pour remplacer sa requête par select * from
COMMENTAIRES c1 inner join COMMENTAIRES_EXTRA c2 on c1.Id = c2.Id
il faut recompiler l'appli
il faut redéployer l'appli aux utilisateurs
2ème cas:
on remplace la requête dans la procédure sp_GetCommentaires et l'appli
n'y voit que du feu!!!
Ok dans la vraie vie je ne gére pas les commentaires de cette manière mais
l'exemple est très parlant... je pense.
bonne soirée.
"Sylo" <devbnet@[antispam]free.fr> wrote in message
news:eINBFldyFHA.1552@TK2MSFTNGP10.phx.gbl...
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
Bonjour,
2. Cacher la complexité de la base à l'application (c'est à mon avis le
point le plus important), exemple classique (et fictif):
Une table est constituée ainsi :
Create table COMMENTAIRES (Id int PRIMARY KEY, Commentaire1 nvarchar(1000),
Commentaire2 nvarchar(1000), Commentaire3 nvarchar(1000))
Une application quelconque affiche dans un datagrid le contenu de la table
commentaires.
1er cas : l'appli envoie un select * from COMMENTAIRES
2ème cas : l'appli appelle une procédure sp_GetCommentaires qui renvoie le
même select * from COMMENTAIRES
Les utilisateurs souhaitent obtenir une 4ème colonne de commentaire qui soit
également un nvarchar(1000):
d'un point de vue modelisation dans sql server on ne peut décemment pas
ajouter cette colonne dans la table commentaires car avec cette nouvelle
colonne on dépasserait la limite des 8000 octets gérables dans une ligne de
table. On s'exposerait à de la perte de données utilisateurs.
Donc on crée une 2ème table:
Create table COMMENTAIRES_EXTRA (Id int PRIMARY KEY, Commentaire4
nvarchar(1000))
L'importance de la procédure stockée apparait maintenant:
1er cas:
il faut modifier son appli pour remplacer sa requête par select * from
COMMENTAIRES c1 inner join COMMENTAIRES_EXTRA c2 on c1.Id = c2.Id
il faut recompiler l'appli
il faut redéployer l'appli aux utilisateurs
2ème cas:
on remplace la requête dans la procédure sp_GetCommentaires et l'appli
n'y voit que du feu!!!
Ok dans la vraie vie je ne gére pas les commentaires de cette manière mais
l'exemple est très parlant... je pense.
bonne soirée.
"Sylo" <devbnet@[antispam]free.fr> wrote in message
news: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
Thierry a écrit:Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
Thierry a écrit:
Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
Thierry a écrit:Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
Thierry a écrit:Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
Thierry a écrit:
Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
Thierry a écrit:Il y a également un cache des commandes SQL très efficace dans SQL
Server.
Il y a aussi le SqlPrepare ou bien la possibilité de créer manuellement
la procédure temporaire avant de s'en servir...
A ce propos, à l'aide de l' "analyseur de profils" , a t-on un moyen de
voir si SQL Server a utilisé un plan exécution déjà présent dans son
cache, pour executer une commande.
Non, mais tu peut le faire en lisant la table des éléments en cache :
SELECT * FROM master..syscacheobjects
Et là tu va voir des surprises et notamment pourquoi je préconise
d'installer son serveur avec une collation binaire !!!
Parce que pour lui, deux requêtes identiques avec des éléments de casse
différents sont 2 objets différents. Il fait son analyse sur la chaine de
car représentant la requête !
DBCC FREEPROCCACHE
GO
SELECT * FROM master..syscacheobjects
GO
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'SYSCONSTRAINTS'
GO
SELECT *
FROM ionformation_schema.columns
WHERE table_name = 'sysconstraints'
GO
SELECT sql FROM master..syscacheobjects
A +
--
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 ***********************
