Discussion :

[jeoff]

Bonjour

Mon projet commence tout juste et je coince déjà

Voici la problématique :

Nous désirons créer une table des articles.
Le soucis c'est que ces articles peuvent être de nature très différentes.
On a donc opté pour une table principale assez générique que l'on vient remplir avec des "paramètres" sous forme numérique.

Voici en quelques mots l'architecture initiale :

Une table article :
# id
nom (int)
variete (int)
conditionnement (int)

Chaque champs de la table article est un paramètre (sauf l'id).
Chaque paramètre possède sa propre table.

table nom :
# id
value (String 50)

table variete :
# id
value (String 50)

table conditionnement :
# id
value (String 50)

------------

Donc comme ces tables de paramètres ont le même format, il paraît clair qu'à partir d'un unique formulaire, je dois pouvoir renseigner n'importe laquelle d'entres elle.

Tout mon soucis c'est d'arriver à modéliser celà pour pouvoir générer mon squellette sous AndroMDA.

------------

Mon idée initiale est de créer une table (genre de metadata) référençant les noms des paramètres, les noms des tables qui les contiennent (champs is_table) ainsi qu'un champs de commentaire.




Ca vous semble correct comme démarche ? Vous avez une meilleure idée ?
J'ai l'impression de ne pas prendre le problème par le bon boût

Merci

[Inpri-V]

Si tes tables table nom, variete et conditionnement ont la même structure et les même comportement (selon ta description) il n'est pas nécessaire de créer une classe pour chacune.

Ta classe (table) paramètre pourrais avoir la structure:
# id
Type : Type de paramêtre
value (String 50)

et une nouvelles classe de "Type de paramêtre"
Type
Description

[jeoff]

Au début j'ai trouvé ton idée un peu "folklorique".
On mélange des choux et des carottes dans la même table

Mais a la réflexion, ca reste des paramètres quoi qu'il arrive donc ca se défend .

Par contre du coup c'est assez statique comme archi.
Si un jour un paramètre a besoin de 2 champs (+id) au lieu d'un

Je vais y réfléchir

Merci

[Inpri-V]

Il y a toujours un moment où une classe doit devenir statique.
Si tu a besoins d'avoir un nombre aléatoire d'attribut d'un paramètres, fait pointer ton paramètre sur lui même

[jeoff]

Le nombre d'attributs n'est pas aléatoire.

Disons que pour chaque paramètre, on partirait avec 1 attribut.

Mais on peux décider en cours de route de préciser cet attribut.

Par exemple, pour une variété, on pourrait dans un premier temps avoir la nom commun puis decider d'y associer le nom scientifique.

Auquel cas ce paramètre reçoit un champs supplémentaire mais qui est toujours rempli (chaque champs d'une table paramètre sera non null).

Si j'ai bien compris ta suggestion, il faudrait faire une jointure de la table sur elle même pour retrouver tous les attributs d'un même paramètre ?