Discussion :

[jean jojo]

Bonjour à tous,

J'ai créé une table qui est enregistre les informations sur des clients. Mon problème est qu'en fait je veux que l'une de ces colonnes puisse contenir plusieurs données un peu comme une wishlist composée de plusieurs produits, mais je ne sais pas comment faire pour retourner un produit en particulier de la wishlist.

Merci pour votre aide

[tatayo]

Bonjour,
C'est une très mauvaise idée. Une colonne => une donnée.
Tu devrais donc plutôt ajouter une table qui fait le lien entre le client et le produit.

Tatayo.

[Darkzinus]

Bonjour, il s'agit en effet d'une mauvaise idée (pour le cas que tu cites). Cela pourrait être utilisable si la colonne était pensée comme un champ libre.

[jean jojo]

Bonjour,
C'est une très mauvaise idée. Une colonne => une donnée.
Tu devrais donc plutôt ajouter une table qui fait le lien entre le client et le produit.

Tatayo.

merci beaucoup mais comment suis je censé faire le lien?

[jean jojo]

Bonjour, il s'agit en effet d'une mauvaise idée (pour le cas que tu cites). Cela pourrait être utilisable si la colonne était pensée comme un champ libre.

Ah d'accord, je comprends. Merci

[tatayo]

merci beaucoup mais comment suis je censé faire le lien?

Comme avec n'importe quelle table: tu y mets (entre autre) deux colonnes, l'une qui contient l'id du client, l'autre l'id du produit, chacune avec une contrainte d'intégrité.
Tu y ajoutes une colonne auto-incrémentée qui est l'identifiant de la ligne, et ensuite les données annexes: quantité, date d'ajout… bref ce dont tu as besoin.

Tatayo.

[jean jojo]

c'est compris je vais le faire .Merci beaucoup pour votre aide

[escartefigue]

Comme avec n'importe quelle table: tu y mets (entre autre) deux colonnes, l'une qui contient l'id du client, l'autre l'id du produit, chacune avec une contrainte d'intégrité.
Tu y ajoutes une colonne auto-incrémentée qui est l'identifiant de la ligne, et ensuite les données annexes: quantité, date d'ajout… bref ce dont tu as besoin.

Tatayo.

Si la table en question est issue de la relation entre CLIENT et PRODUIT, alors il ne faut pas lui ajouter d'identifiant primaire, son identifiant primaire sera la concaténation de l'identifiant client et de l'identifiant produit, chacun de ces identifiants faisant en effet référence à la table issue de l'entité-type CLIENT et PRODUIT du MCD.

[tatayo]

En fait ça dépend, est-ce qu'un lien entre un client et un produit est unique ou pas ?

Tatayo.

[escartefigue]

Non, ça ne dépend pas : vu que le besoin est de pouvoir enregistrer tous les produits souhaités pour un client, sauf à considérer qu'un produit est mono-client (ce serait un cas très très particulier qui mériterait d'expliquer le contexte...) on a bien un modèle conceptuel

CLIENT 1,n --- souhaiter --- 0,n PRODUIT

Donc des cardinalités max "n" de part et d'autre, ce qui implique la génération d'une table issue de l'association "souhaiter"

Cette table aura pour PK ID_client + ID_produit dans cet ordre ou pas

[tatayo]

Je suis tout à fait d'accord sur le modèle, il faut bien une table d'association entre Produit et Client.
Ce que je voulais dire, c'est qu'on n'a pas tous les détails concernant le besoin initial, donc on ne sait pas si le couple Produit/Client est unique (même si tout semble l'indiquer, je l'admets).
Si oui, alors je te rejoins, le couple idClient/idProduit sera la clé.
Sinon, il faut bien ajouter un id dans cette table.

Tatayo.