Discussion :

[devnino]

Beau soir tout le monde, j'espère que vous vous portez en paix.

Je développe une application WPF concernant la gestion du stock d'une boutique de type Vêtements pour Homme.

La marchandise s'achète sous forme de séries de produits. Une série d'un Produit possède de multiples Couleurs et chaque Couleur possède une gamme de taille [plusieurs tailles.] Sachant que chaque série du même Produit peut s'acheter avec un prix différent dans un autre temps.

Je me suis résumé à modéliser les tables comme suit;

Table Produit: * Id * Étiquette * Marque * Catégorie

Table VarienteProduit: * Id * idProduit * Couleurs // Représente une collection de couleurs du Produit. * Prix_Achat * Prix_Vente

Table Couleur: * Id * CouleurReference * idTailles // Représente une gamme de tailles pour la Couleur.

Table Taille: * Id * TailleReference * Quantité * Codebarre

L'ajout coté application se fait par série et non pas une seule variante à la fois [pour gagner du temps]. C'est à dire qu'on renseignent le Produit [Champ de texte dédié] s'il n'existe pas, ainsi que ces couleurs [d'une listbox,] sans oublier la gamme des tailles qu'on aura sélectionnée.
Je n'aurai qu'à crée un nouvel objet Série en liant directement ces propriétés Produit, Couleurs aux champs respectés (Textbox, Listbox,) Sans oublier oublié de lier la gamme des tailles à chaque Couleur, j'aurai quelque du genre;

Série 1: Produit A, de Couleurs:
Rouge de tailles;
38, de quantité 1
40, de quantité 2
41, de quantité 4
Bleu de tailles;
38, de quantité 1
40, de quantité 2
41, de quantité 4
Noir de tailles;
38, de quantité 1
40, de quantité 2
41, de quantité 4

J'ai fais ainsi pour que le marchant puisse rectifier l'erreur suite à l'ajout de la série, en éditant cette dernière que la dite modification s'applique sur l'ensemble de la série sans qu'il perd son temps à modifier une à une les entrées récentes.

Le hic dans tout cela, c'est qu'ils me proposent une autre approche, celle de supprimer les tables Couleurs & Tailles et ne gardé que la VarianteProduit comme suit:

Table VarianteProduit:

* Id
* idProduit
* Couleur // Représente une seule couleur.
* Taille // Représente une seule taille.
* Prix_Achat
* Prix_Vente


Ce qui donne:

Série 1 avec le Prix d'Achat, Prix de Vente possédant:
-----------------------------------------------------
Produit A, Rouge, 38
Produit A, Rouge, 39
Produit A, Rouge, 40
Produit A, Rouge, 41

Produit A, Blue, 38
Produit A, Blue, 39
Produit A, Blue, 40
Produit A, Blue, 41

Produit A, Blanc, 38
Produit A, Blanc, 39
Produit A, Blanc, 40
Produit A, Blanc, 41
-----------------------------------------------------

Je n'arrive pas à me décider, en ayant qu'une seule table possédant tous les variantes de tous les produits avec leurs caractéristiques, même si cela pourrai paraitre redondant comme montré ci-dessus ou dois-je découper en tables Produit + Couleurs et Couleur + Tailles, sachant que cela soit adapté au WPF.

Des conseilles ? Orientations ?
Merci.

[micka132]

Très franchement ton problème n'a que peu avoir avec WPF.
Plus généralement tu ne devrais pas conceptualiser ton problème pour répondre à une contrainte IHM...
Tu devrais donc plutôt demander du coté du forum modélisation.

[champy]

De mon point de vue un produit est un produit avec sa taille et sa couleur, un produit petit et vert n'as pas la même référence dans le stock chez le revendeur qu'un produit gros et rouge. Sinon personne ne les retrouverait
Par conséquence :
- la table taille et la table couleurs sont lié à la table produit, un produit à un id taille et un id couleur.
- la table couleur n'as pas d'id taille (remplacer par l'id taille du produit).
- la table produit n’a pas de collection de couleur.
- ajout d'une colonne référence dans la table produit (référence unique du revendeur), avec une clé unique.
- si pour un 'de tes anciens produits sans couleurs ni taille' tu as 3 couleurs et 6 tailles tu as 18 lignes dans la nouvelle table produit qui ont toute la même étiquette (que tu complètes dans l'interface avec la taille et la couleur).
- une clé unique sur les colonnes étiquette, id taille et id couleur de la table produit pour éviter les doublons.
- une clé unique sur la colonne CouleurReference de la table couleur pour éviter les doublons.
- une clé unique sur la colonne TailleReferencede la table taille pour éviter les doublons.
- des pks sur les ids forcément.

Mais effectivement c'est une question de modélisation.

[MABROUKI]

bonjour

Un mix des 2 solutions cites est nécessaire :
- les couleurs possibles doivent entre en base ce qui exige une table Couleur avec minimum un champ string Couleur Clé-les tailles également ...avec minimum un champ string Taille clé...

-la table produit ayant la structure de la dernière variante proposé...

L'intérêt des tables Couleur et Taille est de limiter les choix à des gammes de couleur et taille prédéfinies disponibles avec possibilité de rajout dans le futur...
L'intérêt de lier les Tables Couleur et Taille me parait superfétatoire, et peut compliquer inutilement la gestion des tables, car il introduit une liaison de second degré dans les tables ....