Discussion :

[illight]

Bonjour,


J'ai une question un peu tordue : j'ai une table, disons la table "possession", avec un Id, et différents attributs, qui sont des cases vrai ou faux.

La table se définirai donc ainsi :
Id
ElementA
ElementB
ElementC
ElementD

Pour chaque id, une personne a différents éléments, mais tout le monde n'a pas les mêmes. Ce qui donnerait un résultat de ce genre (en csv):
1;Vrai;Faux;Vrai;Faux
2;Faux;Faux;Vrai;Faux
3;Vrai;Vrai;Vrai;Vrai


Je voudrais un requête SQL, afin d'avoir, par ID, uniquement les éléments où c'est "Vrai".

De ce fait, par exemple, la première requête me donnerait alors :
1;ElementA;ElementC pour l'ID1
1;ElementC pour l'ID2
etc...

Je ne peux pas faire un simple Select, car il faudrait que je fasse des "Ou" dans tous les sens, ce qui serait, en soit, faisable, mais je pense pas que ça soit la meilleure solution.

Quelqu'un aurait une idée pour savoir comment faire une requête de ce genre ? (si mon explication est claire )


En vous remerciant par avance de vos réponses

[al1_24]

Quelque chose comme ça :

Code :

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

1
2
3
4
5
6
select  id
    ,   case ElementA   when 'vrai' then ';ElementA' else '' end
    ||  case ElementB   when 'vrai' then ';ElementB' else '' end
    ||  case ElementC   when 'vrai' then ';ElementC' else '' end
    ||  case ElementD   when 'vrai' then ';ElementD' else '' end
from    matable

[aieeeuuuuu]

Bonjour

Votre modélisation est mauvaise, et c'est ce qui rend votre requete compliquée.

Vous devriez avoir une table de trois colonnes : id, element, valeur

elle contiendrait alors, pour votre exemple :

1 A vrai
1 B Faux
1 C Vrai
1 D Faux
2 A Faux
2 B Faux
2 C Vrai
...

Voire même uniquement les deux premières colonnes. elle ne contiendrait alors que les lignes pour lesquelles la valeur est vraie (à voir en fonction du besoin fonctionnel)

Avec une pareille table, vous pourrez même ajouter un cinquième élément sans modifier la structure de la table !


La requete deviendrait alors :

Code :

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

1
2
3
4
 
SELECT id, Element
FROM LaTable
WHERE Valeur = 'Vrai'

Qui ne retournera que les lignes à vrai

Le mieux serait donc de revoir la modélisation. (Votre modélisation ne pourra que vous mener à des requêtes complexes et non performantes)

En alternative, vous pouvez "simuler" cette modélisation à partir de votre modélisation actuelle grâce à une série d'UNION ALL

Code :

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

1
2
3
4
5
6
7
8
 
SELECT id, 'A', ElementA FROM LaTable
UNION ALL
SELECT id, 'B', ElementB FROM LaTable
UNION ALL
SELECT id, 'C', ElementC FROM LaTable
UNION ALL
SELECT id, 'D', ElementD FROM LaTable

[aieeeuuuuu]

Quelque chose comme ça :

oui, aussi

[François DORIN]

Votre modélisation est mauvaise, et c'est ce qui rend votre requete compliquée.

Je ne suis pas d'accord. Ce qui rend la requête compliquée ce n'est pas le modèle, mais la requête elle-même SQL et la concaténation d'un nombre dynamique d'éléments mène qu'à des requêtes compliquées.

La requête que tu proposes ne répond pas à la question. Enfin que partiellement, car il n'aura bien que les éléments 'VRAI', mais il aura une ligne par élément et par ID, alors qu'il souhaite une ligne par ID avec la concaténation des éléments.
Sans plus d'information sur le contexte, difficile de juger de la pertinence du modèle. En tout cas, cette requête seule ne le permet pas.

[aieeeuuuuu]

oui, c'est vrai ! al1_24 l'a d'ailleurs montré pendant que j’écrivais mon message.

Je maintiens toutefois que la modélisation est mauvaise, et qu'elle mènera à des requêtes plus compliquée, et surtout moins performantes dans bien des cas, par exemple "quel sont les id ayant au moins un élément à vrai"

Concernant le résultat de ma requete, elle renvoi bien les bonnes données, certes pas présentées comme voulu, mais là ce n'est plus le rôle du SGBD (même s'il existe des solutions pour ce faire).

[François DORIN]

Je maintiens toutefois que la modélisation est mauvaise, et qu'elle mènera à des requêtes plus compliquée, et surtout moins performantes dans bien des cas, par exemple "quel sont les id ayant au moins un élément à vrai"

Et plus performante dans d'autres, par exemple, quel sont les éléments ayant à la fois A, C et pas B D'où ma remarque sur la difficulté de juger de la pertinence du modèle sans en savoir plus sur le contexte.

Concernant le résultat de ma requete, elle renvoi bien les bonnes données, certes pas présentées comme voulu, mais là ce n'est plus le rôle du SGBD (même s'il existe des solutions pour ce faire).

On est d'accord. Et avec le modèle actuel, sa requête est extrêmement simple si la concaténation est faite dans une couche métier : un simple SELECT, sans jointure ! (comme quoi sa modélisation n'est pas si mal faite )

[aieeeuuuuu]

Là encore, tu as raison !

J'ai été péremptoire en voyant la structure de la table telle que décrite par illight, mais nul doute qu'il s'agit en fait d'une adaptation de la réalité.

donc en effet, sans connaitre mieux le contexte, ma conclusion sur la modélisation est trop hâtive.

[illight]

Bonjour,


Je suis désolé, étant beaucoup pris, j'avais oublié cette requête et que j'avais écrit ici.

Effectivement, c'est un adaptation un peu biscornue de ce que j'ai en réalité.

Tout d'abord, je vous remercie pour vos réponses, mais la réponse par rapport à une succession de UNION est ce que je voulais éviter.

Je vais donc vous expliquer le contexte réel, qui vous permettra surement de comprendre mon besoin plus clairement.

Tous les jours, je reçois des dossiers clients, que je dois envoyer. Avant de les envoyer, je dois vérifier s'il ne manque pas des pièces à mes dossiers, de façon à pouvoir les envoyer à l'organisme concerné.
Si ces dossiers sont incomplets, je dois alors envoyer le courrier à un autre organisme, de façon à ce qu'il contacte le client, afin qu'il nous fournisse les pièces manquantes.

Pour cela, j'ai donc une table "Dossier", où j'ai différentes informations client, avec, évidemment un ID correspondant à chaque dossier.
Lorsque le dossier est incomplet, j'ai une table "Incomplet", qui, par ID, me permet de détailler les pièces manquantes du dossier.

(Pour tout vous dire, je gère tout cela dans une base Access, avec des formulaires derrière. mais j'ai posé la question ici car pour moi, c'est purement un problème de requête SQL)

Dans cette table "incomplet", j'ai donc différents attributs, qui constitue les différentes pièces du dossier, qui seraient susceptibles d'être manquantes. Donc, dans cette table, j'ai des attributs :
ID
Pièce A
Pièce B
Pièce C
Pièce D
etc...

(j'en ai à peu près 15 comme ça, mais c'est un nombre fixe par contre de cases à cocher, si jamais ça peut aider...)
Et tous ces attributs sont de type booléen, vu que derrière, je les utilise en case à cocher.

Qui sont gérés dans un formulaire, où, lorsque le dossier est "collecté" dans ma base Access, la personne qui ajoute les informations a juste des cases à cocher pour indiquer les pièces manquantes.

De ce fait, par la suite, j'ai un résultat tel que je vous ai énoncé au dessus, ou je n'ai pas forcément mes 15 cases qui sont cochées, mais que certaines, et ce ne sont, évidemment, pas forcément les mêmes cases pour chaque client.

J'espère que mon besoin est plus clair maintenant

Pour répondre, tout de même, je ne sais pas sic 'est un problème de modélisation, c'est fort probable, peut-être que j'ai mal construit mes tables au départ, mais je ne savais pas comment les construire autrement. S'il y a une solution plus simple que celle que j'ai faite, et qui serait plus facile à gérer, je suis preneur

[illight]

Bonjour

Votre modélisation est mauvaise, et c'est ce qui rend votre requete compliquée.

Vous devriez avoir une table de trois colonnes : id, element, valeur

elle contiendrait alors, pour votre exemple :

1 A vrai
1 B Faux
1 C Vrai
1 D Faux
2 A Faux
2 B Faux
2 C Vrai
...

Voire même uniquement les deux premières colonnes. elle ne contiendrait alors que les lignes pour lesquelles la valeur est vraie (à voir en fonction du besoin fonctionnel)

Avec une pareille table, vous pourrez même ajouter un cinquième élément sans modifier la structure de la table !


La requete deviendrait alors :

Code :

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

1
2
3
4
 
SELECT id, Element
FROM LaTable
WHERE Valeur = 'Vrai'

Qui ne retournera que les lignes à vrai

Le mieux serait donc de revoir la modélisation. (Votre modélisation ne pourra que vous mener à des requêtes complexes et non performantes)

Après mûre réflexion, et avoir relu 3 fois ce que tu as écrit, j'ai peut-être effectivement fait une erreur de modélisation, au vu du résultat que je veux obtenir.

Il faudrait effectivement que je remodélise ma table Incomplet.

En suivant cette logique, il faudrait que dans ma table "Incomplet" j'ai un Id pour chaque case à cocher c'est ça ? et après, faire une autre table où cet ID apparaitrait, et le résultat si c'est vrai ou faux ??
Ou j'ai mal compris ?

Merci pour ta réponse

[StringBuilder]

Regarde la réponse de al1_24.

Il faudra peut-être adapter à Access, car je ne suis pas certain que ça soit supporté par Access (mais il y a à coup sûr une fonction proprio qui fait la même chose).


En fait, pour déterminer, si la modélisation est bonne ou non, il faut avant tout se poser la question de la pertinence et de la réalité des valeurs "Vrai" et "Faux".
En effet, ici, "vrai" et "faux" peuvent être assimilés à "non null" et "null".

Sur un dossier, j'ai un certain nombre de pièces (avec leur ID, etc.) ou pas.

Donc si vous stockez dans votre base le détail des pièces, alors il y a une erreur de conception : chaque pièce doit pointer sur son dossier, et c'est l'ensemble des pièces renseignées qui détermine si un dossier est complet ou non (d'autant que souvent, une pièce peut en replacer une autre : par exemple, pour une démarche administrative, si on a un passeport, on n'a pas besoin de carte d'identité, et vice versa).

Si en revanche "l'information" que vous stockez, c'est pas les pièces justificatives, mais simplement leur présence, alors votre modélisation me semble correcte.

Sinon, dans tous les cas, ce que vous cherchez à faire, c'est avant tout de la cosmétique : quelle que soit votre modélisation, la génération de la liste des pièces présentes (ou absentes) à partir de vos données doit se faire dans la couche applicative et non pas dans la couche SQL, qui ne sert qu'à obtenir l'information, pas à la mettre en forme.

[illight]

Ok, ça me rassure pour la modélisation : c'est effectivement juste pour voir si la pièce est présente ou pas.

Il me semble que c'est faisable dans Access, je vais voir ce que je peux faire.

En tout cas, je remarque, finalement, que je vais être obligé de passer par une requête complexe pour faire ce que je souhaite, et donc liste finalement tous les attributs de ma table dans ma requête ça va faire un sacré paquet de lignes

[StringBuilder]

Ok, ça me rassure pour la modélisation : c'est effectivement juste pour voir si la pièce est présente ou pas.

Il me semble que c'est faisable dans Access, je vais voir ce que je peux faire.

En tout cas, je remarque, finalement, que je vais être obligé de passer par une requête complexe pour faire ce que je souhaite, et donc liste finalement tous les attributs de ma table dans ma requête ça va faire un sacré paquet de lignes

Au risque de me répéter, vous feriez mieux de faire ce boulot dans votre application cliente, et non en SQL, qui est là pour interroger les données, et non les mettre en forme.