Bonjour.
 
 
Mon application possède toute une liste de prospects.
Chaque prospect peux souscrire à plusieurs produits différents.
Il peux par exemple avoir souscrit à 3 assurance santé (ses enfants), 2 assurances auto moto.
 
Les tables secondaires sont en fait les tables concernant les produits souscrits, elles sont donc toutes différentes dans leur structure.
 
Et moi ce que j'aimerai faire avec ma requête c'est pouvoir récupérer tout les produits de chaque prospect en fait.
 
La structure de ma BDD est celle ci (dans chaque table de produit il y a bien entendu une référence à l'ID du prospect).
 
    * assanim (table d'un produit)
    *  automoto (table d'un produit)
    *  budgetor (table contenant les infos prospects)
    *  depend (table d'un produit)
    *  dotation (table d'un produit)
    *  finance (table d'un produit)
    *  grev (table d'un produit)
    *  habitprinc (table d'un produit)
    *  habitsc (table d'un produit)
    *  immeub (table d'un produit)
    *  lowimp (table d'un produit)
    *  mapad (table d'un produit)
    *  obseque (table d'un produit)
    *  pjfisc (table d'un produit)
    *  pnoccup (table d'un produit)
    *  prevdc (table d'un produit)
    *  rccansf (table d'un produit)
    * retraite (table d'un produit)
    *  sante (table d'un produit)
 
Merci à vous.

Et tu as essayé quoi?

J'ai essayé cela

 
Mais à priori il y a de gros problèmes dans les résultats retournés.

Renverse tes clauses car tu es en LEFT JOIN :

pecky -> je viens de tester et bizarrement ca me renvoi la même chose.
 
Avec des résultats bizarre.

 
Comme vous pouvez le voir pour la table DOTATION aucun champs n'est retourné alors que pour finance oui, c'est pour ca je me demandais si ma requête était bonne ou pas.

Perso j'ai du mal à comprendre ton résultat mais lorsque tu fais un left outer join, tu ramènes les données de la table en jointure si la condition de jointure est vérifiée.
Es-tu sur que tu as des éléments dans ta table dotation qui soient en relation avec ta table budgetor?
Essaye la requete simple :

pecky -> Dans ma requête de test a aucun moment il y a une dotation .ID_BUDGETOR = budgetor.ID_BUDGETOR et rien n'est renvoyé, mais pour d'autres ou c'est la mêmes chose les champs sont renvoyés!!!!
 
Sinon ta requête me retourne 13 enregistrements avec tout les champs à NULL ce qui est normal car il n'y a aucune souscription à dotation pour le moment.
 
Cela est pareil pour  sante, aucune souscription et pourtant dans ma première requête très longue les champs sont retournés.
 
C'est cela que je ne comprends pas!!!!!!!
Avec ta requête de test si je met santé ca retourne 6 résultats avec que des champs à NULL!!
 
Alors pourquoi dans ma longue requete les champs de sante sont retournés et non ceux de dotation!!!!
 
Si je fait un test avec une dotation de souscrite, on voit que seul l'ID est retourné alors que pour finance tout les champs sont retournés tout en étant NULL!!!!
 
[IDDOTATION] => 16/03/2008 12:57-2 [IDFINANCE] => [MONTANTS1] => [SUPPORT1] => [MONTANTS2] => [SUPPORT2] => [MONTANTS3] => [SUPPORT3] => [MONTANTS4] => [SUPPORT4] => [MONTANTS5] => [SUPPORT5] => [IDGREV] =>
 
Mystère.

ton modèle me semble absolument foireux dans la mesure ou si comme dans ton exemple, t'as souscrit à 3 assurances santés et 2 assurance moto, pour un unique budgetor_id, tu va avoir 6 lignes, avec toutes les combinaisons possible de assurance santé / assurance moto parmis les assurances souscrites.
 
sans oublier que devoir faire autant de jointures (externes qui plus est) pour ne retourner que si peu d'information, y'a une couille dans le potage.
 
tu ferais mieu de dénormaliser ton modèle pour n'avoir qu'une seule table produit selon moi.
 
Note subsidiaire : va faire un tour ici histoire de comprendre comment avec une "unique table" tu peux gérer tous tes types de contrats (et même créer de nouveaux types de contrats ou modifier leur structure dans le temps, sans avoir besoin de modifier le code source de ton programme ou le modèle de données)
http://forum.hardware.fr/hfr/Progr [...] m#t1668734

Merci MagicBuzz je vais aller voir ca.
 

Il faudrait donc créer une classe mère produit  et ensuite des tables filles avec en plus les champs qui les différencient?
Cela sous entend que la table produit devra contenir tout les champs communs de nos produits?

Ca, c'est effectivement la première étape, telle qu'elle est imposée par la méthode MERISE si on la suit à 100% : aucune redondance.
 
La méthode évoquée dans mon lien permet d'éviter de gérer 36 tables filles, en se basant sur une structure permettant de gérer les différentes informations de chacune des tables filles. Ceci implique en revanche un certain nombre de contraintes supplémentaires, mais cela permet d'ajouter à la volée de "nouvelles tables filles" sans devoir toucher au code ni à la base de données.