Discussion :

[Pascal]

Bonjour,

Je voudrais un petit conseil pour une de mes applis. Je vais devoir gérer des produits avec 3 niveaux de classification.

Groupe produit
Famille produit
Sous famille produit

Je voudrais savoir si il vaut mieu faire une table Classification (sachant que bien sur ma table produit est à part) ou 3 tables (Groupe, famille, SFamille).

Merci pour vos réponses

PAscal

[cmen76]

Je pense qu'il ne peut pas y avoir de bonne réponse à ta question.

Il paraîtrait plus "propre" de créer une table par niveau de classification, mais cela risque d'alourdir le code et les temps d'exécution.

Intuitivement, je te dirais que la solution adéquate est fonction
- de l'intérêt stratégique de cette classification (info obligatoire ?, utilisation dans le reste de l'appli ?)
- du nombre de valeurs et de l'évolutivité de ces classifications (des constantes ne seraient-elles pas plus appropriées ?, la hiérarchisation doit-elle être si fine ?)

Se poser aussi la question du bien-fondé d'une classification sur 3 niveaux hiérarchiques si l'on permet par ailleurs des recherches ou des extractions suffisamment souples...

[Pascal]

Merci pour ta réponse,

Effectivement j'ai besoin d'une classification aussi fine (produits alimentaires). Effectivement au début je désirais créér 3 tables afin de pouvoir avoir une certaine souplesse et plus de facilité à gérer. En revanche j'ai entendu d'autres son de cloche m'indiquant qu'il valait mieux tous mettre dans une seule table.

Ma classification groupe sera sur environ 6 enregistrements chacun des groupes aura entre 30 te 50 familles et chaque famille aura entre 20 et 30
sous familles.

Il faut que l'utilisateur puisse ajouter un nouveau groupe, une nouvelle famille et une sous famille. Il faut quelque chose d'évolutif.

A savoir que quand je recherche un produit je doit pouvoir le faire sur la classification ou sur de l'alpha.

Pascal

[cmen76]

En bon Normand, je me dirigerais vers une solution mixte
Les groupes risquent de ne pas évoluer --> constantes (à toi de prévoir peut-être un 7e groupe Divers...)
une table famille avec pour clé primaire groupe, famille_id
une table ssfamille avec pour clé primaire groupe,famille_id, ssfam_id
une clé étrangère entre les 2 sur (groupe, famille_id)

ça décharge déjà un niveau !

maintenant, ça dépend aussi du SGBD choisi, et de ses performances...

[Manopower]

le plus simple à gérer et le plus évolutif sera effectivement de créer 3 tables. Le son de cloche qui te disait de ne faire qu'une seule table avait dû sécher ses cours d'analyse quand il était à l'école. le fait de faire 3 tables te simplifera la vie aussi en programmation Delphi puisque, par exemple tu pourras faire une DBGrid par table (tu disais que l'utilisateur doit pouvoir ajouter un groupe, une famille, une sous-famille....)

[pit9.76]

si j'ai bien compris chaque produit appartient a un groupe une famille et une sous famille ?

si c'est le cas pourquoi ne pas ajouter dans ta table produit contenant les caractéristiques du produit 3 champs supplémentaire : un champ groupe , un champ famille et un champ sous-famille ?

[Pascal]

Merci pour vos réponses,

Je penses comme Sylvain, la solution 3 tables serait la plus tangible( évolution et souplesse).

pit9.76, ma table produits contiendra obligatoirement les 3 champs(sinon ma classification ne sert à rien). Mais au départ je fournis à l'utilisateur une structure de classification et un certain nombre de fiche produits mais il n'y aura, peut-être, au départ pas une fiche produit par sous-famille, donc faut que l'utilisateur ai des groupes, familles et sous famille déja établis. Libre à lui d'en rajouter ou d'en modifier.

Pascal