Discussion :

[Dark Matter]

Bonjour à tous !

Je suis en pleine galère sur une vue qui m'est demandé et je voudrais faire appel à votre aide. Je schématise l'éxistant, voici en gros ce qui m'est présenté: la colonne Champ peut contenir n'importe quoi et un formulaire peut contenir n'importe quel nombre de champs. Puis, un champ contient une valeur:

idFormulaire | Champ | Valeur
________________________________
1 | EMail | email 1
1 | Nom | Nom1
1 | Societe | Societe 1
---------------------------------------------
2 | Email | email 2
2 | Nom | Nom 2
----------------------------------------------
3 | Company | Company 1
3 | Country | Country 1
3 | Language | Language 1
3 |Comments | commentaires

Mon travail consiste à faire un pivot de ces Champs pour en faire des colonnes grace à une vue. Ceci doit donner pour la requete ci dessous

-> Select * from maVue where idFormulaire = 1:

-> idFormation | Email | Nom | Société
-------------------------------------------------
1 | email 1| Nom1 | Societe 1


Apparament SQL Server 2005 permet grace à "Pivot" de faire ce genre de manipulation (et encore, peut-on faire un pivot d'un nombre indéfini de lignes ?). Ne travaillant que sous SQL Server 2000, comment est ce que je peux m'y prendre à votre avis ?

merci d'avance pour votre aide

[SQLpro]

1) la notion de PIVOT n'existe pas dans le langage SQL
2) même si pivot existe dans SQL 2005 c'est une grosse connerie, car tout ceci est de la csométique.

Donc à faire sur le client, pas sur un serveur SQL; Le serveur SQL il a autre chose à foutre que de faire de la cosmétique !

A lire :
http://sqlpro.developpez.com/SQL_Server_2K5/N1.php
paragraphe 1.8 et surtout la remarque
et
http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L9

A +

[eomer212]

la question est ancienne, mais je n'y resiste pas.
je viens de consulter un blog microsoft traitant de l'application Vinci et en particulier du projet "SQL Server 2-D Matrix Builder" . bon, c'est pas mal pour celui qui veut faire bosser son serveur sql pour autre chose que de la fourniture de données, ca a l'air de pouvoir faire des choses trés puissantes, certes. (voir ici http://msdn2.microsoft.com/fr-fr/sql.../cc197167.aspx
bon, pas mal, ca génére une tonne de requete et de création de tables temporaires sur le serveur, etc.. pour des choses finalement trés simples à faire par un client. d'où quand même la reflexion suivante..
Microsoft a privilégié (ou du moins les développeurs de microsoft) l'utilisation de frameset. certes, c'est plus rapide et facile à développer. ca gére les requetes, mises à jour de données, etc avec ADO, c'est super génial..
mais quand on veut faire ce qu'il veulent faire la, ben c'est quand meme déplacer largement le probleme là ou il n'a pas lieu d'être, car créer des tables temporaires et des routines executées sur le serveur juste parceque le codeur de l'application ne sait pas trier ses retours de données, ni les présenter, ca fait un peu faineasse tout de même, pour ne pas dire con, car, et ca microsoft a l'air de s'en foutre royalement, un serveur, c'set fait pour servir de la donnée, pour la cracher par wagon entiers, pas pour s'amuser à y faire des petits tris et autres arrangements "cosmétiques" comme dit SQLpro.
pour répondre, maintenant, à la question originale, il vaut mieux, à mon sens faire un composant réutilisable, privilégiant le retour de données valides dans un minimum de volume (et oui, on l'oublie souvent, mais il y a encore des gens qui se connectent en RTC, mais sans aller jusque là, les connexions mobiles sont quand même limitées) si vous êtes comme moi, vous en avez peut être ras le bol de rester devant votre navigateur à attendre que le serveur asp veuille bien instancier une foule d'objet dhtml pour ensuite me les balancer à l'écran. sauf que j'en ai eu marre d'attendre et que j'ai fermé mon butineur depuis longtemps.
pour les clients sur base de données, c'est pareil.
si votre client ne peut pas mettre en forme par lui même les données renvoyées, c'est soit que vous avez pas le niveau, soit que les données elles memes sont mal, (trés mal ) organisées ou stockées. c'est toute la création de la base de données qui doit être alors revue.
concernant l'accés par butineur, à mon sens une page asp ou php doit être capable de génerer une mise en forme de tableau de données en y faisant un pivot. et toujours en permettant un minimum de charge sur le serveur de données.
si les developpeurs ne savent pas faire ca, il y a comme un probleme.
et cela elimine donc, systématiquement, toute notion même de pivot dans une base de données. (ca n'a vraiment rien à y faire.)

[olymars]

Bonsoir,

Je suis le développeur du projet dont vous parlez dans votre rajout. Je vous trouve bien catégorique et j'aimerais juste nuancer votre propos et vous proposer mon point de vue.

1/ J'ai utilisé la fonctionnalité de SQL Server 2005 qui permet d'exécuter du code .NET directement dans le moteur de la base de données. Ce ne sont pas des tables temporaires qui sont utilisées ici mais des traitements en mémoire. Il n'y a aucune requête qui est générée. Pour chaque exécution de matrice, il y'a trois requêtes qui sont exécutées (et qui sont fournies et donc optimisées par l'utilisateur lui-même), celle qui remplit la première colonne, celle qui remplit les en-têtes de colonnes et enfin celle qui remplit les données.

2/ Vous parlez fort justement du fait que tout le monde n'est pas en connexion haut-débit et vous souhaitez réduire les échanges au maximum. Or la solution que vous proposez (à savoir laisser le client gérer les données) va à l'opposé de votre affirmation, contrairement à l'utilisation de cette Matrice qui elle, ne renvoit que les données strictement utiles. Dans l'exemple que j'utilise dans mon article, votre solution renvoit 29 chaînes de caractères et 69 entiers tandis que l'exécution de la matrice renvoit 24 chaines de caractères et 0 entier. Comme vous le voyez, le gain en quantité de données transmis est assez net.

De manière générale et à mon humble avis, l'informatique est toujours une affaire de compromis à un instant t et en fonction d'une situation précise (et donc rarement un jugement extrême de type blanc ou noir) et heureusement ! C'est cela qui fait tout son charme !

Bonne soirée !

Pascal Belaud
Microsoft France
http://blogs.msdn.com/Pascal
Article cité plus haut: http://msdn2.microsoft.com/fr-fr/sql.../cc197167.aspx

[Antoun]

Apparament SQL Server 2005 permet grace à "Pivot" de faire ce genre de manipulation (et encore, peut-on faire un pivot d'un nombre indéfini de lignes ?). Ne travaillant que sous SQL Server 2000, comment est ce que je peux m'y prendre à votre avis ?

merci d'avance pour votre aide

Un pivot "statique" est assez facile à faire en SQL. Supposons par exemple que tu saches à l'avance que tes champs ne peuvent être que "Nom", "Societe" et "Email" :

Code :

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

1
2
3
4
5
SELECT idFormulaire, Ch1.Valeur AS Nom, Ch2.Valeur AS Societe, Ch3.Valeur AS Email
FROM maTable F
  LEFT JOIN maTable Ch1 ON F.idFormulaire = Ch1.idFormulaire AND Ch1.Champ = 'Nom'
  LEFT JOIN maTable Ch2 ON F.idFormulaire = Ch2.idFormulaire AND Ch2.Champ = 'Societe'
  LEFT JOIN maTable Ch3 ON F.idFormulaire = Ch3.idFormulaire AND Ch3.Champ = 'Nom'

Pour un pivot "dynamique" comme le tien, càd sans connaître à l'avance les champs possibles, il faut passer par une proc stock. Celle-ci doit commencer par faire un SELECT DISTINCT Champ, et ensuite rédiger dynamiquement la requête sur le modèle de celle qui est ci-dessus.

En termes de performances, ça risque évidemment de ne pas être terrible si tu as trop de valeurs différentes de Champ...

[EDIT]Je viens de retrouver la discussion où j'avais codé un truc très proche... :http://www.developpez.net/forums/sho...light=crois%E9

[al1_24]

La remarque de SQLpro est toujours d'actualité :

1) la notion de PIVOT n'existe pas dans le langage SQL
2) même si pivot existe dans SQL 2005 c'est une grosse connerie, car tout ceci est de la csométique.

Donc à faire sur le client, pas sur un serveur SQL; Le serveur SQL il a autre chose à foutre que de faire de la cosmétique !

A lire :
http://sqlpro.developpez.com/SQL_Server_2K5/N1.php
paragraphe 1.8 et surtout la remarque
et
http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L9

A +

[Antoun]

La remarque de SQLpro est toujours d'actualité :

Je suis d'accord sur le fond.

[SQLpro]

Je suis le développeur du projet dont vous parlez dans votre rajout. Je vous trouve bien catégorique et j'aimerais juste nuancer votre propos et vous proposer mon point de vue.

Salut pascal, content de te voir fréquenter developpez.com...

Pour revenir sur le débat... De toute façon il faudra toujours au moins une requête et qu'elle soit jaune, verte ou à pois, le nombre de données dans la matrice sera toujours le même...
Donc si l'on doit la générer des milliers de fois (ce que par principe doit faire un SGBDR) alors il convient que ce soit la requête la plus optimisée, ce qui n'est pas le cas de l'opérateur PIVOT.

Quand à ta méthode (je ne la connais pas) mais elle me semble un compromis entre les deux mondes. C'est donc déjà mieux que le tout PIVOT ! Et c'est de toute façon le seule solution si dynamicité il y a.

A +

[olymars]

Salut pascal, content de te voir fréquenter developpez.com...
A +

Coucou Fréd! Ben c'est un plaisir ! Ca a l'air animé

Quand à ta méthode (je ne la connais pas) mais elle me semble un compromis entre les deux mondes. C'est donc déjà mieux que le tout PIVOT ! Et c'est de toute façon le seule solution si dynamicité il y a.
A +

Dans le cas du "SQL Server 2-D Matrix Builder", c'est toi, utilisateur, qui fournit les trois requêtes (litéral SQL ou SP, avec ou sans paramètres en entrée) pour remplir les axes et le contenu de la matrice et cette librairie ne fait rien d'autres que de les invoquer et préparer le Resultset à renvoyer.

Si tu as un moment, je veux bien que tu testes ça sur les cas tordus qui ont l'air de te poser soucis. Ton feedback "will be greatly appreciated" comme on dit :-)

A+

Pascal

[SQLpro]

Coucou Fréd! Ben c'est un plaisir ! Ca a l'air animé

J'essaye de mettre un max de piment ! je suis connu pour cela ;-)

Si tu as un moment, je veux bien que tu testes ça sur les cas tordus qui ont l'air de te poser soucis. Ton feedback "will be greatly appreciated" comme on dit :-)

Pourquoi pas ? Mais je vais devoir décliner, hélas : trop de boulot et pas le temps de me plonger dans Visual Studio. Néanmoins ce serait intéressant de faire un petit article sur ce sujet. Il y a en effet des demandes régulières sur le sujet...

Propose le aux gens de VS / .net.

A +

[olymars]

trop de boulot et pas le temps de me plonger dans Visual Studio.

Non, non, point de Visual Studio ici ! Le but est d'utiliser la Matrice directement depuis T-SQL, c'est tout l'objectif de cette librairie.

Dès que tu as une minute (priorité au taf évidemment), jette un coup d'oeil à l'article, il est assez explicite :

http://msdn2.microsoft.com/fr-fr/sql.../cc197167.aspx

Bonne continuation en tout cas !