SQL Server 2005 et fonctions dans les requêtes - SQL/NoSQL - Programmation
Marsh Posté le 10-10-2007 à 16:11:38
ReplyMarsh Posté le 10-10-2007 à 16:32:35
deuz
Marsh Posté le 10-10-2007 à 16:35:29
heureusement que vous êtes là
Marsh Posté le 10-10-2007 à 17:34:02
bon tout le monde s'en fout de mon problème qui me bloque complètement et qui arrive pile au moment de ma négociation de salaire ?
Marsh Posté le 10-10-2007 à 17:43:04
Très honnêtement, je ne vois pas pourquoi ça merde.
Question bête cependant... T'as combien de ligne dans ta table ?
En effet, la première ligne ne sera retournée que lorsque la clause WHERE sera entièrement vérifiée, ce qui implique l'exécution de ta fonction pour toute les lignes de la table avant de retourner la moindre ligne.
En revanche, la fonction dans le select n'est évaluée que lorsque les lignes commencent à arriver (à condition qu'aucun critère de tri ne pointe dessus évidement). Ainsi, tu as des lignes retournées dès qu'un nombre suffisant pour remplir la première page de buffer est traîtée. Sur un gros volume, on se rend bien compte que ça change du tout au tout.
Tu peux tester :
1/ Clause HAVING, qui permet de faire un critère sur le résultat d'une requête (à mon avis ça ne marchera pas mieux)
2/ Faire un select global qui filtre le résultat de la première requête. A mon avis, tu vas pas gagner grand chose, voir rien du tout.
Est-tu vraiment obligé de passer par la fonction ? Effectivement, c'est mieux de refactoriser, mais dans ton cas, une jointure pourrait s'avérer bien plus rapide.
Marsh Posté le 10-10-2007 à 18:01:21
MagicBuzz a écrit : Question bête cependant... T'as combien de ligne dans ta table ? |
dans la vue VInfosCompletes, juste 17038
MagicBuzz a écrit : En effet, la première ligne ne sera retournée que lorsque la clause WHERE sera entièrement vérifiée, ce qui implique l'exécution de ta fonction pour toute les lignes de la table avant de retourner la moindre ligne. |
effectivement, ça risque de poser quelques problèmes de lenteur
MagicBuzz a écrit : En revanche, la fonction dans le select n'est évaluée que lorsque les lignes commencent à arriver (à condition qu'aucun critère de tri ne pointe dessus évidement). Ainsi, tu as des lignes retournées dès qu'un nombre suffisant pour remplir la première page de buffer est traîtée. Sur un gros volume, on se rend bien compte que ça change du tout au tout. |
okay
MagicBuzz a écrit : Tu peux tester : |
1/ http://msdn2.microsoft.com/en-us/library/ms180199.aspx
Citation : When GROUP BY is not used, HAVING behaves like a WHERE clause |
donc je doute que ça change quoi que ce soit (d'autant plus qu'avec ça, il veut à tout prix que je fasse un aggregate, sauf que j'ai pas du tout envie)
2/ je vois pas trop ce que tu veux dire
MagicBuzz a écrit : Est-tu vraiment obligé de passer par la fonction ? Effectivement, c'est mieux de refactoriser, mais dans ton cas, une jointure pourrait s'avérer bien plus rapide. |
non, je suis pas obligé, c'est juste la seule méthode que j'ai trouvé
avec une jointure, tu voudrais faire comment ?
Marsh Posté le 10-10-2007 à 18:45:27
perso je passerai par l'explain plan pour déja voir un peu,
j'essayerai aussi sans l'order by car du coup il ne serait plus obligé d'avoir l'entiereté des records pour fetcher et au moins tu verrais peut-etre apparaitre qques records.
j'aurai aussi tendance a virer ceci pendant la phase de debug
Code :
|
Marsh Posté le 11-10-2007 à 10:06:07
explain plan ? wtf ?
l'order by c'est nécessaire malheureusement
et la sous-requête aussi
Marsh Posté le 11-10-2007 à 10:16:09
ben euuhhh le plan d'exécution, la manière dont le sgbd va construire ta requete, j'ai du jouer 2* avec du microsoft mais y a un tab avec ca tout fait dans le machin enterprise bidule non?
je sais bien que l'order by et la sous requete sont nécessaires, mais je les virerai pour voir ce qui impacte tes perfs et tu les remets après et peut-être pas tel quel
Marsh Posté le 11-10-2007 à 10:29:35
Pour faire apparaître le tab il faut avant aller dans une option dans "affichage" ou un truc du genre.
Sinon, +1 pour le mode "pas à pas" :
"select 1"
=> F5.
Après on commence à discuter, à ajouter une table à la fois, et un champ à la fois, histoire de localiser exactement quel bout de la requête ralenti de façon significative.
Ca va bien plus vite comme ça.
En effet, en plus de la fonction, il se peut que ça merde ailleurs. Des fois le SQL c'est très chiant pour ça T'as un big bug. C'est bien, super rapide. Tu rajoutes un truc qui est bon, et proutch, ça ramme à donf. Tu t'escrimes à debug un truc juste, alors que ct avant que ça merdait
Marsh Posté le 11-10-2007 à 10:33:19
okay, j'essayerais avec le plan d'exécution
Marsh Posté le 11-10-2007 à 10:35:48
au fait, truc qui n'a rien à voir, mais c'est pour la beauté de l'art :
Code :
|
C'est plus joli comme ça :
Code :
|
Marsh Posté le 11-10-2007 à 10:50:23
ah oui pas con (je connaissais pas isnull mais je connais coalesce, qui fait pareil)
Marsh Posté le 11-10-2007 à 10:54:43
bon, j'ai fait ça complètement différemment, et ça marche
(j'ai mis la fonction dans le select, et à l'affichage, je test si la structure de prêt est la même que la structure de jeu)
merci pour votre aide, les tips m'aideront quand-même pour la suite
Marsh Posté le 10-10-2007 à 16:02:00
Hello
J'ai un tout petit problème qui me bloque depuis ce matin
J'ai besoin du résultat d'une fonction dans une clause WHERE.
Lorsque je mets ma fonction dans le select, ça marche impec :
Mais lorsque je mets ma fonction dans la clause WHERE, ça me fait un timeout :
J'ai essayé de feinter en mettant un alias au résultat de ma fonction, et en testant sur cet alias, mais ça marche pas (ça serait trop beau)
du coup je comprend pas trop
ma fonction :
et voici ma requête :
quelqu'un pour m'aider ?
---------------
Android/Manettes/Metroidvania/Zelda/Indés/Retrogaming/VDS jeux