Discussion :

[k'n1]

Salut a tous,

apres bien longtemps sans trop me faire entendre, je reviens pour poser quelques questions.. je bosse sur du SQL en ce moment, mais je ne suis pas encore familier avec tout ca, notamment MS SQL Server.

Par avance mes excuses si le sujet est traite de facon identique ailleurs, je n'ai rien trouve en FAQ / lien PDF / recherche google (ou presque). J'ai tente de faire un titre aussi clair que possible pour aider ceux qui chercheraient sur google la meme chose que moi...

Passons au sujet. Voila ce que j'ai appris au cours de mes recherches :

Type des fonctions

• Scalar UDF : on renvoie des type de base (entier, varchar...), pratique dans une definition de table pour creer un attribut qui s'informe automatiquement (un peu redondant en volume de donnees mais permet de simplifier ses requetes d'insertion puis de selection - selon moi)
• Inline Table Value UDF : on renvoie une table, alternative aux vues
• Multi Statement UDF : on retourne une table "faite maison", avantage d'une grande flexibilite et complexite face a une vue.

inconvenient fonctions :

• on ne peut pas faire appel a des fonctions indeterministes dans une fonction. on peut passer outre ceci en mettant la fonction indeterministe en parametre d'entree si on en a besoin un nombre fini de fois.
• problemes de performance ? (a confirmer car j'ai juste lue une phrase sans argumentaire)
• probleme des fonctions indeterministes

avantage fonctions :

• on peut faire des calculs sur les parametres d'entree dans la ligne d'apel a la fonction (contrairement a une procedure)
• Plus de possibilites a pas mal de niveaux, notamment des appels tres flexibles (appel dans une clause select, dans une clause from pour les 2 derniers types, dans une definition de table...)

Conclusion
A vrai dire, de ce que j'en ai lu, j'ai limite l'impression que ces fonctions sont vraiment geniales. Eventuellement je vois un petit soucis du cote des getdate() qui limitent a des sections de code pas enorme, mais a part ca...

voila, je suis preneur de toute information complementaire pour confirmer ou infirmer ce que j'ai trouve, en esperant que ca vous inspire (notamment les plus experimentes ^_^), merci d'avance

[SQLpro]

Limitation des fonctions :

Une fonction ne peut JAMAIS comporter une transaction !

C'est normal car une fonction peut être utilisée dans une requête qui est elle même une transaction.

Utilisation des fonctions :

La présence d'une fonction dans une requête interdit toute optimisation possible du prédicat comportant la fonction.

La présence d'ne fonction table dans une requête interdit toute optimisation sur les lignes de la table produite par la fonction

C'est donc très contre performant en général d'utiliser les fonctions...

Les fonctions doivent donc être réservées à l'obtention de "petites" données :
valeur scalaires, tables de faible volume (quelques lignes).


A +

PS : si vous venez à mon cours d'optimisation de MS SQL Server à ORSYS, vous y découvrirez ce genre de choses... http://www.orsys.fr/pdfCours/SQO.pdf

[k'n1]

Ok, je vois, merci pour les infos.

Du coup, pour peu que l'on conserve des faibles flux de donnees et des petits bouts de code, on peut se servir de tout ca sans perte de performance n'est-ce pas ?

je vais lire le PDF pour mieux voir de quoi il en retourne..

En ce qui concerne le cours, merci mais je crois que j'aurais du mal a parcourir 6000 kilometre chaque soir pour venir y assister

[k'n1]

Utilisation des fonctions :

La présence d'une fonction dans une requête interdit toute optimisation possible du prédicat comportant la fonction.

La présence d'ne fonction table dans une requête interdit toute optimisation sur les lignes de la table produite par la fonction

J'ai une autre interrogation a ce propos : si tu as 2 structures totalement identiques deja optimisees, et que tu decides de les reunir en une seule fonction pour alleger un peu le code, ton optimisation est fait n'est-ce-pas ?

par consequent, quand tu parles d'impossibilite d'optimisation, tu consideres le cas ou l'on ecrit une fonction a usage general (et donc contenant des infos inutiles notamment) ?

[SQLpro]

Soit plus précis. C'est quoi une structure ???

A +

[k'n1]

Autant pour moi, je n'utilise pas vraiment le bon vocabulaire

Tu parle d'impossibilite d'optimisation, mais si tu as 2 portions de codes identiques (contenues dans des procedures differentes), et que tu factorise tout ca en creant une fonction dont l'unique utilite est de regrouper ces lignes de code similaires, tu ne perds rien en efficacite n'est-ce pas (et donc ton code est aussi optimal que si tu n'avais rien fait, mais ca permet de normaliser un peu ton code - comme dans n'importe quel langage de prog en fait), n'est ce pas ?

Par contre maintenant que je me relis, j'ai un peu de mal a comprendre le lien entre ce que je dis et ce que je cite -_-... jolie memoire ^_^

[rudib]

Bonjour,

Un moteur SQL ne peut vraiment être comparé à un compilateur ou un interpréteur de langage procédural/objet. La différence est que le moteur SQL a des informations sur les données qui doivent être traitées et sur le système sur lequel il s'exécute. Par exemple il maintient des statistiques de distribution de valeurs dans des index ou des colonnes, qui lui permettent, avec un code SQL donné, de construire un plan d'exécution optimisé.

Sachant cela, il est important en écrivant ton code de faciliter le travail de l'optimiseur pour qu'il puisse créer le meilleur plan d'exécution possible. Si tu écris un seul SELECT, l'optimiseur a la possibilité de comprendre les relations entre les tables. Si tu déplaces une partie de ce SELECT dans une fonction, tu vas obliger l'optimiseur à passer dans ta fonction pour chaque ligne retournée par le SELECT, ce qui peut être très contre-productif.

C'est principalement en cela que les fonctions sont à double tranchant.