Discussion :

[fluctus]

Un petit challenge pour se dégourdir les neurones ? ;-)

Question pour un CTO (ou un Lead Dev) :
Quelle solution d’implémentation choisir ?

Contexte :
Il s'agit d'un logiciel de préconisation de produits (des prothèses auditives).
Le logiciel devra gérer un catalogue avec des produits aux caractéristiques techniques évolutives,
au fil des progrès technologiques à venir.

Le problème :
comment stocker en base de données des produits dont
les caractéristiques vont évoluer de façon imprévisible ?

On cherche une solution :

• simple
• mais pas simpliste
• capable de suivre l'évolution des caractéristiques techniques à venir dans le domaine des aides auditives, sans pour cela nécessiter de modifier le code de l'application...

Quelle architecture choisirais-tu pour garantir flexibilité et maintenabilité sur le long terme ?

- Il s'agit à l'origine d'un cas réel auquel j'ai été confronté lors de ma 1ere année de travail,
après ma formation de AFPA Développeur Informatique -
Je suis curieux de découvrir d'autres solutions possibles et d'autres façons d'envisager les choses.

[tatayo]

Bonjour,
Dans les grandes lignes :

1. une table Produit
2. une table Caractéristique
3. une table associative entre les deux, avec la valeur

Ainsi la création d'une caractéristique se résume à ajouter une ligne dans la deuxième table.
Et dans la "fiche produit" dans l'application, une liste construite à partir des deux dernières tables permet d'avoir la liste des caractéristiques et leurs éventuelles valeurs.

C'est la solution que j'avais mise en place, avec en plus la possibilité de créer des groupes de caractéristiques, pour simplifier la saisie (un moulinet n'a pas les mêmes caractéristiques qu'une canne à pêche).

Tatayo

[fluctus]

Bonjour,
Dans les grandes lignes :

1. une table Produit
2. une table Caractéristique
3. une table associative entre les deux, avec la valeur

Ainsi la création d'une caractéristique se résume à ajouter une ligne dans la deuxième table.
Et dans la "fiche produit" dans l'application, une liste construite à partir des deux dernières tables permet d'avoir la liste des caractéristiques et leurs éventuelles valeurs.

C'est la solution que j'avais mise en place, avec en plus la possibilité de créer des groupes de caractéristiques, pour simplifier la saisie (un moulinet n'a pas les mêmes caractéristiques qu'une canne à pêche).

Tatayo

Simple et efficace.
Dans mon cahier des charges, il fallait que notre client puisse ajouter 1 fichier de description du nouveau produit.
J'avais choisi à l'époque (2007) des fichiers xml, mais peut-être qu'aujourd'hui je ferais en json ?