Forum d'entraide PHPFrance

Bonjour, je solicide de nouveau votre aide précieuse.

Suite à un changement dans ma base je pense avoir besoin de liens identifiants pour des produits
j'ai une base produit, un produit appartient à un catégorie, et une catégorie correspond à un département :
Un produit peut avoir une et une seule catégorie, Il peut y avoir plusieurs produit pour une même catégorie.
Une catégorie peut avoir une et une seul catégorie, il peut y avoir plusieurs Catégorie pour un même département.

Je souhaite que mon produit soit identifié grace au NumCategorie, NumDepartement et sa place dans cette catégorie pour ce département. Je ne sais pas trop si vous voyer ce que je veux dire, cela ferait une sorte de modélisation en triangle.
c'est à dire un produit ayant comme référence ( 100802 ) 02 le département, 08 la catégorie et le 02 voudrait dire que ce serait le deuxième produit pour cette catégorie et ce département.

Je ne cite que les clés primaires et clés étrangères.
Produit(NumProduit, NumCategorie#, NumDepart#, ....) //Mon produit 100802, le 02 pourrait être le NumProduit ?? on m'a dit qu'il fallait mieux avoir un Numéro incrémenté pour ne pas avoir de problème.
Categorie(NumCategorie, NumDepart#,...)
Departement(NumDepart,....)

Je suis vraiment perdu pour effectuer cette modélisation, mais surtout pour la faire correspondre aux règle de gestion du deuxième paragraphe. C'est surtout que je peine à bien effectuer mes règles de gestions. Suis-je obligé de passer par des liens identifiants ?
Help.

Merci de m'aider.

Bonjour.

1. Ton message devrait plutôt aller dans la catégorie BDD/MySQL.

2. Que veux-tu dire par "liens identifiants" ? Et par "place

3. Modélisation :
- Ne surtout pas faire ce que tu envisages (une référence composée de plusieurs codes).
- Tes tables semblent correctes. Ne pas oublier que le 02 du produit n'a pas vraiment de signification (le 2ème produit dans quel ordre ?).
- Pour quelle raison logique une catégorie ne se retrouve que dans un département ? Tu ne donnes pas de précisions. Pareil pour les produits, je ne vois pas trop pourquoi un produit est limité à un département...

Bonjour,

2) Je veux dire par lien identifiants hum, que la clé primaire est composée de deux lignes, comment dire ?? ^^ C'est à dire (1,1),
par exemple que une table au lieu d'avoir comme clé primaire NumProduit, la table aura comme clé primaire le Numproduit ainsi que le NumCategorie qu'elle héritera.

3)Je suis obligé de différencier la catégorie et le département, je créé une catégorie pour faire un tri plus facile des produits, et je dois laisser le département, c'est pour trier les produits pour effectuer des statistiques sur les ventes (les départements de la caisse enregistreuse)

Je veux utiliser une référence composée du numéro de catégorie, du département, car mon patron envisage un étiquetage des produits en inscrivant la ref pour s'y retrouver plus facilement, il envisage aussi un jour utiliser un lecteur de code-barre.

Pour mon "02": je pensais à une numérotation des produits de façon à ce qu' un produit puisse avoir le même num qu'un autre mais comme il est identifié aussi par la catégorie, à mon sens ça aurait pu fonctionner je ne vois pas comment j'aurais pu faire.

Moi au départ je voulais faire un numproduit autoincrément puis un tri par catégorie et département, ça marche très bien, puis mon patron m'a imposé cette méthode pour la référence donc ça me complique énormément la chose, comment pourrais-je avoir une numérotation dans la même idée ??

2) Je veux dire par lien identifiants hum, que la clé primaire est composée de deux lignes, comment dire ?? ^^ C'est à dire (1,1),
par exemple que une table au lieu d'avoir comme clé primaire NumProduit, la table aura comme clé primaire le Numproduit ainsi que le NumCategorie qu'elle héritera.

On parlera plutôt de clé composée, alors...

3)Je suis obligé de différencier la catégorie et le département, je créé une catégorie pour faire un tri plus facile des produits, et je dois laisser le département, c'est pour trier les produits pour effectuer des statistiques sur les ventes (les départements de la caisse enregistreuse)

Je ne sais pas dans quoi tu travailles, mais si on prend - par exemple - une chaîne de magasins de bricolage :
- "Marteau" fait partie de la catégorie "Outils".
- On peut fournir des "Marteaux" dans tous les départements.
Si on suit ton principe, on va se retrouver avec une table Produits (Dépt, Catégorie, Produit) :
Ain, Outils, Marteau
Aisne, Outils, Marteau
...

La logique voudrait qu'on ait une table Produit (Catégorie, Produit) :
Outils, Marteau

Après, si tu parles de stocks (voire de ventes), il faut effectivement le département. Mais il n'y a pas besoin de mettre la catégorie (qui reste la même quel que soit le département)
Dans ce cas, j'aurais tendance à faire une table Stocks (id_stock*, id_produit#, id_dept#, quantité)

Je veux utiliser une référence composée du numéro de catégorie, du département, car mon patron envisage un étiquetage des produits en inscrivant la ref pour s'y retrouver plus facilement, il envisage aussi un jour utiliser un lecteur de code-barre.

Pour mon "02": je pensais à une numérotation des produits de façon à ce qu' un produit puisse avoir le même num qu'un autre mais comme il est identifié aussi par la catégorie, à mon sens ça aurait pu fonctionner je ne vois pas comment j'aurais pu faire.

Moi au départ je voulais faire un numproduit autoincrément puis un tri par catégorie et département, ça marche très bien, puis mon patron m'a imposé cette méthode pour la référence donc ça me complique énormément la chose, comment pourrais-je avoir une numérotation dans la même idée ??

Là j'avoue que je ne comprends plus trop ce que tu veux faire
Ce que je peux te dire, c'est que même si au final ton patron veut avoir une référence DDCCPP (Département+Catégorie+Produit), tu peux/dois stocker autrement dans ta BDD. Ce n'est que de l'affichage...

Oui c'est l'affichage, je parle de département au niveau de la caisse enregistreuse. j'ai parlé de mon problème à ma prof qui me suis, elle m'aidera un peu, merci pour m'avoir aider =). Ton idée de table stock est plus intéressante, ça serait plus malin.