Discussion :

[steph5555]

Bonjour a tous,

J'ai un probleme qui peu paraittre simple mais je ne vois pas comment faire.

J'ai le modele ci-dessous :



Comment faire pour qu'un client aie plusieurs montres.
Client 1-----Inf Montre
Quel peut-etre le denominateur commun ?

Desolé mais je ne vois pas?

Pouvez-vous m'eclairer ?

Merci
Stéphane

[User]

Bonsoir,

Si la relation 1 à plusieurs est uniquement dans le sens client->Montres et pas l'inverse alors il faudrait placer une clé étrangère "ID_client" dans la table "Montre" de façon à faire le lien avec la table "client" sur ces champs.

Cdlt,

[ClaudeLELOUP]

Bonjour,

Comme d’une part
- un objet appartient à un client et a été livré par un vendeur ;
- le SAV est lié à un objet ;
- montre et bijou ont des caractéristiques spécifiques ;
- les caractères du SAV d’une montre diffèrent de ceux du SAV d’un bijou,
Je verrais plutôt les choses comme ceci :

[steph5555]

Bonjour

Merci à vous 2 pour votre aide.

Sans remettre en question ta proposition, claudeLELOUP (je ne me permettrais pas) mais mon projet et pas mal abouti si je change toutes mes tables.... ca fait un gros chamboulement. merci en tous cas.ton alanyse est exactement ca.

User: J'ai fais ce que tu m'as conseillé, a savoir l'inverse de ce que j'avais fais. c'est impecable tout rentre dans l'ordre. Merci

merci pour votre aide

Stéphane

[steph5555]

Bonjour ClaudeLELOUP,

Je me permet de revenir sur ce post dans lequel tu es intervenu.
Tu as publié un modèle (ci-dessus) dont j'aimerai avoir quelques explications.

Dans la table tMontres, il y a le champs tMontresPK que veux-tu dire par l’appellation PK ? (Primary Key ???)

Idem dans la table tSAVMontres, tMontresFK, que veut dire FK ?

J'ai une autre question qui découle de cela, les 2 tables nommées ci-dessus ont une relation tMontresPK----->tSAVMontresFK. je pense que ce qui peut les relier est le numero de serie des montres qui est unique. mais parfois il est possible pour de multiples raisons que le numéro de série ne soit pas lisible ou que la montre n'en ai pas. Or, ces champs ne peuvent pas rester vide et doivent être unique. comment faire?

merci pour votre aide.
Stéphane

[ClaudeLELOUP]

Bonjour Stéphane,

Je crois que c’est une bonne habitude de choisir un champ NuméroAuto comme clé primaire d’une table.
Je le fais systématiquement.
J’ai aussi pris l’habitude de suffixer le nom de cette colonne avec PK (Primary Key).

Quand, une autre table contient aussi cette valeur en tant que clé étrangère (donc quand une relation est définie entre elle et la précédente), je nomme ce champ avec un suffixe FK (Foreign Key).
J’adopte cette attitude même si un autre champ de la table contient une valeur unique.

Pour imposer qu’un champ soit impérativement rempli et unique :

[steph5555]

Merci pour ta réponse bien pertinente, c'est bien car cela nous aide a adopter une méthode de travail clair.

Peux-tu m'eclairer sur ce point également ?

J'ai une autre question qui découle de cela, les 2 tables nommées ci-dessus ont une relation tMontresPK----->tSAVMontresFK. je pense que ce qui peut les relier est le numéro de série des montres qui est unique. mais parfois il est possible pour de multiples raisons que le numéro de série ne soit pas lisible ou que la montre n'en ai pas. Or, ces champs ne peuvent pas rester vide et doivent être unique. comment faire?

En faite, je m’aperçois que ce champ "id_serie_montre" apres coup qu'il peut etre vide voir Null. mais comme tu peux le constater c'est la clé primaire (mauvais choix).
Comment puis-je remédier a ce problème ?

[ClaudeLELOUP]

C'est ton modèle qui est boiteux au départ : revois le billet N° 3.

Quand les fondations ne sont pas solides, le bâtiment finit tôt ou tard par se fissurer.

[steph5555]

Bon ba je casse tout alors et je recommence comme proposé...

J’aurai du t’écouter.

merci en tous cas
Stéphane

[ClaudeLELOUP]

Hâtez-vous lentement, et sans perdre courage,
Vingt fois sur le métier remettez votre ouvrage,
Polissez-le sans cesse, et le repolissez,
Ajoutez quelquefois, et souvent effacez.

À la prochaine...