Problème de clé primaire [Résolu]

[ehmppowa]

Bonjour,

je suis en train de développer une application de gestion des locations de ski.

Ma base est très simple. Mes tables sont :
'Client', clé primaie 'id_client'
'article', clé primaire 'id_article'
et ma table associative 'louer', clé primaire ''id_client''id_article''(clé sur 2 champs) et clé étrangère 'id_client' et 'id_article'

Mais comme une clé primaire est toujours unique, je n'arrive pas a mettre le meme article deux fois sur le meme client.

Donc ma question : comment puis-je faire pour que j'y arrive ? Est-ce correct que mes champ ''id_client''id_article'' soit en clé primaire ? il me semble que normalement ils doivent etre en clé étrangère.. est-ce correct ?

Merci d'avance

[efficks]

Tu ne dois pas avoir comme clé primaire client et article puisqu'évidemment il est possible qu'un client loue plus d'une fois le même article. Donc tu dois ajouter une nouvelle clé comme un numéro de location par exemple.

Et le numéro article et client sont bel et bien des clé étrangères dans ta table location.

[Sieldev]

Je suis d'accord avec efficks.
Je suppose que les régles de gestion sont les suivantes:
Un client peut louer aucun ou plusieurs articles
Un article peut être loué par aucun ou plusieurs clients
Tu as donc 0,n des deux cotés.

Ce n'est pas la peine de mettre une clé primaire dans ta table Louer, ta table louer sert d'association entre tes tables Client et Article donc il te suffit de mettre en clés etrangéres id_client et id_article dans ta table louer.

Les clés sur deux champs sont utiles quand il y a une notion d'identifiant relatif.
Pour exemple:

Il y a 3 immeubles se nommant batiment A, B et C.
Je te demande d'aller dans l'appartement 45. Tu vas me demander de quel batiment? Et je repondrai appartement 45 Batiment B.
Si l' on doit adapter ça sur une base de donnée, la table appartement aura deux identifiants: id_appartement et id_batiment.

[overider]

salut


peut être en rajoutant une date clé primaire de ta table associative tu devrais pouvoir t'en sortir

[efficks]

Très mauvaise idée selon moi.
C'est réellement un identifiant unique du même titre que l'id des outils ou des clients qu'il faut.
Si on va dans cette logique de date, le client aussi pourraient avoir une date comme id!

[overider]

salut efficks je pense que l'on ne c'est pas compris


Voila comment j'aurais vu la table louer.

louer(id_client foreignKey+primarykey INT, id_matos foreignKey+primarykey INT, datelocation primarykey datetime)

Cela permets de garder un trace de la date de location pour chaque matos et client.

On pourrait meme aller plus loin en faisant un truc du genre
louer(id_client foreignKey+primarykey INT, id_matos foreignKey+primarykey INT, datedebutlocation primarykey datetime, datefinlocation primarykey datetime)

Si on va dans cette logique de date, le client aussi pourraient avoir une date comme id!

Je comprends pas vraiment ta remarque. Il vaut mieux laisser l'id_client en integer et auto_increment.

Mon Merise est un peu rouilllé il est possible que je dise des betises

bonne soirée

[efficks]

Faut pas exagérer les clés primaires!

Code :

louer(id_location primarykey INT, id_client foreignKey INT, id_matos foreignKey INT, datedebutlocation datetime, datefinlocation datetime)