Mettre lignes en colonnes [Résolu]

[Luzeha]

Bonjour,

J'ai la table suivante :

ID_DECLARATION|ID_MOTIF|NB_JR
101 |20 |2
101 |21 |1
101 |22 |0
101 |23 |0
101 |24 |0
102 |20 |3

etc...

J'aimerai obtenir l'affichage suivant :

ID_DECLARATION|MOTIF_20|NB_JR_20|MOTIF_21|NB_JR_21 etc...

J'ai vu que l'on pouvait utiliser le PIVOT, ou un CASE mais je ne m'en sors pas, si quelqu'un pouvait m'aider ^^

Je travaille sous SQL SERVER 2005

Merci d'avance pour votre aide

[CinePhil]

Ce que tu cherches à faire est de la cosmétique et n'est pas le boulot du SGBD mais celui du logiciel qui présente les données à l'utilisateur.

[aieeeuuuuu]

Envoyé par CinePhil

Ce que tu cherches à faire est de la cosmétique et n'est pas le boulot du SGBD mais celui du logiciel qui présente les données à l'utilisateur.

De plus, même si effectivement tu peux faire ce genre de chose avec PIVOT, cela impose que tu connaisse au moment de l'écriture de la requete la liste exhaustive des lignes a pivoter, en l'occurrence tu dois connaitre la liste des ID_MOTIF !
Si un nouvel ID_MOTIF vient s'ajouter plus tard, il ne sera pas pris en compte, ou alors tu devra modifier ta requete, qui du coup renverra deux colonnes de plus, et donc certainement modifier le programme qui la traite, etc
La seule solution serait de générer dynamiquement ta requete avant de l'exécuter, ce qui est loin d'être propre !

Donc la question est : pourquoi veux tu faire ca ?

[Luzeha]

Le but de ceci est de de créer une vue générale reprenant toutes les informations de toutes mes tables.

C'est cette vue que j'interroge dans mon application cela simplifie et allège toutes les requêtes que je fais dans mon application.

[Luzeha]

Il n'y a que 5 motifs possibles et je ne fais aucun calculs c'est juste de l'affichage.

Un utilisateur déclare une déclaration avec le nombre de jours pour chaque motif (si un motif ne possède pas de jours je met 0 ce qui induit qu'une déclaration aura toujours 5 et seulement 5 motifs).

Mon application interroge un arbre qui regroupe toutes les informations le problème est la redondance à savoir plusieurs ligne sql pour la même déclaration.

A terme la base de donnée possèdera beaucoup de déclarations et je ne peux me permettre de surcharger ma vue en ayant plusieurs lignes par déclaration.

Le but est donc de parvenir à une seule ligne par déclaration.

Au sujet de la mise à jour du nombre de jours par motifs, ma fonction ne passe pas par la vue, elle réécrit directement dans les tables qu'interroge ma vue ainsi les modifications apparaissent bien lorsqu'elles ont lieu.

[aieeeuuuuu]

Je crois que vous faites fausse route...

Envoyé par Luzeha

Il n'y a que 5 motifs possibles et je ne fais aucun calculs c'est juste de l'affichage.

Si c'est juste de l'affichage, raison de plus pour ne pas confier cette tache au SGBDR mais à votre programme

de plus, ceci

Un utilisateur déclare une déclaration avec le nombre de jours pour chaque motif (si un motif ne possède pas de jours je met 0 ce qui induit qu'une déclaration aura toujours 5 et seulement 5 motifs).

explique cela

Mon application interroge un arbre qui regroupe toutes les informations le problème est la redondance à savoir plusieurs ligne sql pour la même déclaration.

C'est votre volonté de "tout regrouper dans une grosse vue" qui est une mauvaise idée dans ce cas. "simplifier l'écriture des requêtes pour le développeur" n'est pas une raison valable pour créer une vue !
Surtout que si vous utilisez des requete de type Pivot, vous ne pourrez pas indexer ces vues !

A terme la base de donnée possèdera beaucoup de déclarations et je ne peux me permettre de surcharger ma vue en ayant plusieurs lignes par déclaration.

Le but est donc de parvenir à une seule ligne par déclaration.

Le but devrait plutôt être de faire en sorte que votre application viennent chercher les informations dont elle a besoin, de la façon la plus optimisée, et non de la façon la plus "facile" !


EDIT : Suppression de paragraphe... j'ai mélangé deux discussions...


Créer une vue pour "regrouper toutes les informations de la base de donnée" est une démarche absurde, contre performante, et vous vous rendrez vite compte que le problème de pivot que vous avez là va se reproduire à chaque nouvelle information à ajouter à la vue.

Au sujet de la mise à jour du nombre de jours par motifs, ma fonction ne passe pas par la vue, elle réécrit directement dans les tables qu'interroge ma vue ainsi les modifications apparaissent bien lorsqu'elles ont lieu.

EDIT : idem...

Un conseil donc, abandonnez cette idée de "vue magique" qui regroupe toutes les informations, vous foncez droit dans le mur.
Le peu d'informations que vous nous avez fournies sur votre base me fait penser qu'elle n'est pas mal modélisée, mais je pense que l'utilisation que vous voulez en faire vous compliquera au final plus la tache qu'autre chose !

[Luzeha]

Pour le principe de faire une vue qui regroupe toutes les informations je suis stagiaire et c'est la manière de faire de l'entreprise dans laquelle je travaille.

Petite précision je ne fais aucun calcul dans mes requêtes, les chiffres ne sont pas des sommes, ils sont ce que l'utilisateur saisit.

Voici une partie de mon MCD :

T_DECLARATION (idDeclaration, dateDebut, dateFin)
T_MOTIF (idMotif, libelleMotif, nbJrMotif)
T_DECLARATION_MOTIF (#idDeclaration, #idMotif)

[aieeeuuuuu]

Envoyé par Luzeha

Pour le principe de faire une vue qui regroupe toutes les informations je suis stagiaire et c'est la manière de faire de l'entreprise dans laquelle je travaille.

etre stagiaire n'empêche pas de prendre des initiatives pour faire cesser de mauvaises pratiques...
Mais je vous l'accorde, c'est parfois plus facile a écrire qu'a faire

Petite précision je ne fais aucun calcul dans mes requêtes, les chiffres ne sont pas des sommes, ils sont ce que l'utilisateur saisit.

oui, désolé, j'ai corrigé mon post, j'ai mélangé cette discussion avec celle-ci
Dans mon post précédent également d'ailleurs

[Luzeha]

Oui c'est sur pour ce qui est de faire changer les habitudes
De toute façon pour le moment j'ai fait autrement, mais je ne sais pas s'ils vont accepter ma solution.

Pour ce qui est de votre confusion, ce n'est pas grave, j'en avais simplement déduit que c'était moi qui avait mal expliqué les choses.

[aieeeuuuuu]

Pour répondre donc a votre question initiale sur la requete pivot, voici le code pour votre cas :

Code sql :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
DECLARE @MaTable TABLE(
	ID_DECLARATION INT,
	ID_MOTIF INT,
	NB_JR INT
)
INSERT INTO @MaTable VALUES(101,20,2)
INSERT INTO @MaTable VALUES(101,21,1)
INSERT INTO @MaTable VALUES(101,22,0)
INSERT INTO @MaTable VALUES(101,23,0)
INSERT INTO @MaTable VALUES(101,24,0)
INSERT INTO @MaTable VALUES(102,20,2)
INSERT INTO @MaTable VALUES(102,21,1)
INSERT INTO @MaTable VALUES(102,22,0)
INSERT INTO @MaTable VALUES(102,23,3)
INSERT INTO @MaTable VALUES(102,24,0)
 
SELECT ID_DECLARATION, [20] AS MOTIF_20, [21] AS MOTIF_21, [22] AS MOTIF_22, [23] AS MOTIF_23,[24] AS MOTIF_24
FROM @MaTable
	PIVOT(SUM(NB_JR) FOR ID_MOTIF IN ([20], [21], [22], [23], [24])) AS MOTIFS

même si comme l'a dit Cinephil, cela ne devrait pas être le travail d'un SGBDR, enfin, il est parfois plus facile de refaire une requete que le monde

[Luzeha]

Houra !!!! Merci milles fois aieeeuuuuu

Tu m'enlèves vraiment une grosse épine du pied

Merci à toutes les personnes ayant participer à cette conversation pour leur aide.