Discussion :

[cahnory]

Bonjour à tous ! Je suis en train de concevoir pour le travaille un backoffice gérant un catalogue. Celui-ci sera rempli en ligne par le client et nous le récupérons via un plugin pour indesign.
La récupération des informations se fait par le biais d'une requête sql (ça passe par le gestionnaire odbc mais je saurai pas du tout vous dire à quoi ça sert ^^ en tout cas ça prend toute requête sql traditionnelle) entré dans le plug-in.
Lors du développement d'une précédente version, j'avais du avoir recours à un script d'export à exécuter avant de mettre à jours les information du catalogue papier apres modification sur la base.
J'ai été obligé de faire ça car les produits du catalogues pouvait chaqu'un avoir un nombre variable de couleurs (, tailles...) mais il fallait que toute les infos d'un produit tiennent en une ligne, hors, les jointures multipliait le nombre de ligne.
Codant la nouvelle version j'aimerai à présent éviter d'avoir à passer par ce script car au passage il empêche l'utilisation d'une fonctionnalité du plugin qui est de pouvoir modifier les infos de la base en modifiant le contenu du catalogue indesign (un retour, plus possible en se servant du script d'export qui génere une nouvelle table).

J'ai fait un petit shéma simplifié pour vous donner une idée de ce que j'aimerai obtenir :

voitures('id','nom'); couleurs('id','nom'); couleur_par_voiture('id','couleur_id','voiture_id');
|
|=>voitures('id','nom','couleur1','couleur2',...);

ou, plus simple :

photos('id','titre'); commentaires('id','photo_id','body');
|
|=>photos('id','titre','body1','body2',...);

Comme vous pouvez le voir en sélectionnant photo et en le joignant à commentaire j'aurai autant de ligne que de commentaire.
J'avoue être à court d'idée là alors je m'en remet à vous.

Merci de votre attention et de vos futures réponses

[ced]

Bonjour,

Si tu ne connais pas le nombre maximal de couleurs, de tailles, de body (etc...), ça n'est pas possible... Il faut, pour cela, faire une jointure par couleur, taille, body. Donc il faut connaître leur nombre à l'avance.

Ce qui est certain, c'est que le SQL n'est pas prévu pour ça, et que c'est du coup plutôt le rôle d'une application de faire la cosmétique des données renvoyées par la requête.

ced

[cahnory]

Merci pour ta réponse, je serrai intéressé de savoir comment c'est possible si l'on connait le nombre de chaque élément.
Merci à toi

[ced]

En fait, dans ton cas, ça n'est pas trop possible.
C'est de ma faute , je n'ai pas trop analysé ton problème. On arrive à tout mettre sur une ligne quand on choisi déjà une couleur (mais pas quand on ne connaît pas la couleur de la voiture à priori). Par exemple, on aura le modèle de voiture et on décline toutes les couleurs en colonnes, et on met des 1 et des 0 si la couleur existe pour ce modèle ou pas. Ca, c'est faisable.
Mais mettre voiture, couleur1, couleur2 en une seule requête, c'est beaucoup plus chaud.
Je pense que c'est faisable en une seule requête, mais c'est juste pour la beauté du sport, parce que ça sera bourré de sous-requêtes et ça aura des performances horribles... ou alors, on peut passer par des tables temporaires...

ced

[cahnory]

Bah en fait tu m'as donné une idée !
Partant du principe qu'il fallait définir le nombre de couleurs au préalable j'ai fait un script d'install qui ajoute des champs à mes tables de tel sorte que je puisse choper toute les infos en un select et quelques jointures.
Comme tu dit, pour la beauté du sport j'aurai aimé gardé mes infos éclatées dans la base et réussir à tout sortir formaté comme je veu en une requête mais bon, je fait pas ça pour le fun, même si ça m'amuse, alors faut avancer et là ça marche !
Merci à toi

Même si techniquement j'ai contourné et non résolu le problème, on peut le considérer ainsi