Discussion :

[paulo6907]

Bonjour à tous,

j'ai besoin d'un coup de main :

voici les tables :
COURRIER COURRIER_DESTINATAIRE DESTINATAIRE
co_id code_destinataire de_id
co_objet code_courrier de_nom

COURRIER_EXPEDITEUR EXPEDITEUR
coex_courrier ex_id
coex_expediteur ex_nom

COURRIER_SECRETAIRE SECRETAIRE
cose_courrier se_id
cose_expediteur se_nom

En clair j'ai une table courrier qui peut avoir plusieurs destinataires, plusieurs secretaires et plusieurs expediteurs

A l'aide d'une requete, je voudrait listeer mes courriers en affichant à chaque fois les destinataires, les expediteurs et les secretaires.

Courrier1 Expediteur1 Destinataire1 Secretaire1
Expediteur2
Expediteur3
Courrier2 Expediteur1 Destinataire2 Secretaire1
Destinataire3
Courrier3 Expediteur1 Dest2 sec2
etc ....

MERCI POUR TOUT CAR JE SUIS DANS LA M....

Pour l'instant je fais un avec un curseur mais ca prend beaucoup trop de temps avec le nombre de courrier ca passe pas.
Si quelqu'un a une idée. Ca à l'air tellement simple que j'y arrive pas.

[paulo6907]

OULA

La description n'est tables n'est pas claire, je recommence donc :

COURRIER
co_id
co_nom

COURRIER_DESTINATAIRE
deco_destinataire
deco_courrier

DESTINATAIRE
de_id
de_nom

COURRIER_EXPEDITEUR
coex_expediteur
coex_courrier

EXPEDITEUR
ex_id
ex_nom

COURRIER_SECRETAIRE
co_courrier
sco_secretaire

SECRETAIRE
se_id
se_nom

[Fleur-Anne.Blain]

Pourquoi tu ne mets pas les informations secrétaires, destinataires, expéditeurs dans ta table courrier avec leurs clefs??

[yoshï]

+1

Je ne comprends pas grand chose à ta modélisation.Tes tables ne sont pas liées...Pas étonnant que tu es du mal à écrire ta requête.
Je te conseil vivement de plancher sur une modélisation type UML avant de te lancer dans l'écriture SQL de ta structure.

une meilleure modélisation:

Courrier
id
id_destinataire
id_expediteur
id_secretaire

justification (par énumération d'hypothèses):
un courrier donné doit être rédigé par une unique secrétaire, expédié par un unique expéditeur et reçu par un unique destinataire

une secrétaire peut rédiger différents courriers, un expéditeur peut expédier différents courriers et un destinataire peut recevoir différents courriers

Les cardinalités sont donc de la forme
Secretaire 1-redige->1..* Courrier
Expediteur 1-expedie->1..* Courrier
Destinataire 1-reçoit->1..* Courrier

Dès lors lister les courrier en affichant secretaire,expéditeur et destinataire devient très simple
select * from Courrier;

ps: l'id du courrier n'est pas necessaire si tu considère qu'il ne peut pas y avoir dans ta table 2 courriers différents qui ont même secrétaire, même expéditeur et même destinataire. Dans ce cas tu peux former une clé sur les 3 attributs.

Voila n'hésites pas si tu as des questions.

[Xo]

Je ne vois pas bien où est le souci dans la modélisation, il y a 4 tables correspondant à des notions distinctes (COURRIER, DESTINATAIRE, EXPEDITEUR et SECRETAIRE), et 3 tables de lien ( COURRIER_DESTINATAIRE, COURRIER_EXPEDITEUR et COURRIER_SECRETAIRE)
=> Un même courrier peut alors concerner plusieurs secrétaires, plusieurs expéditeurs et plusieus destinataires. Oui, peut-être n'y-a-t'il pas besoin de tous ces liens, mais peut-êtrer que si, donc personnellement, je m'estime mal placé pour critiquer le schéma ...

La seule chose que l'on pourrait trouver à redire est d'avoir créer 3 tables pour des personnes, alors qu'une seule, avec un champ pour la typologie, aurait suffit.

Par contre, le souci consiste à consolider ces informations par courrier : si tu lis ce post-ci (Sélection multivaluée), tu verras que le problème est relativement complexe et la solution en SQL n'est supporté que par des SGBD puissants (Oracle, SQL server) dans des versions récentes. La solution de passer par une procédure stockée est donc la plus simple en terme de codage. Si tu as des soucis de performances, vérifie que les champs servant aux jointures sont correctement indexés.

[yoshï]

il y a 4 tables correspondant à des notions distinctes (COURRIER, DESTINATAIRE, EXPEDITEUR et SECRETAIRE), et 3 tables de lien ( COURRIER_DESTINATAIRE, COURRIER_EXPEDITEUR et COURRIER_SECRETAIRE)

Autant pour moi, je n'avais pas vu que les tables courrier_destinataire, courrier_expediteur et courrier_secretaire comportaient la clé de la table courrier (d'où ma reflexion "les tables ne sont pas liées").L'attribut co_id a donc était renommé dans ces trois tables.

=> Un même courrier peut alors concerner plusieurs secrétaires, plusieurs expéditeurs et plusieus destinataires. Oui, peut-être n'y-a-t'il pas besoin de tous ces liens, mais peut-êtrer que si, donc personnellement, je m'estime mal placé pour critiquer le schéma ...

ok si on part de ce principe sa modélisation est correcte.

La seule chose que l'on pourrait trouver à redire est d'avoir créer 3 tables pour des personnes, alors qu'une seule, avec un champ pour la typologie, aurait suffit.

+1