Discussion :

[iNath]

Bonjour ,

je suis actuellement en phase de réflexion sur le développement d'un site web orienté e-commerce. Je me suis fortement inspiré de Magento pour penser mon système de produits.

Seulement, je me rends compte maintenant que le modèle utilisé par Magento pour gérer ses produits est assez déconseillé sur le net, c'est le modèle EAV. Il permet d'avoir des attributs de produits qui ne sont pas connus à l'avance, ni leurs nombre, ni leurs types.
Le problème c'est que je ne vois pas comment faire autrement et j'ai l'impression de découvrir ici une limite des bases de données.

Je viens donc chercher de l'aide ici de la part de personnes qui pourraient me convaincre de ne pas utiliser ce modèle ou, au contraire, modérer les commentaire négatifs que j'ai pu trouver sur le net à propos de ce modèle.

Quel est le prix à payer pour l'utilisation de ce modèle? Existe-t-il des alternatives tout en gardant cette dynamique?

Merci à vous

PS: je ne suis pas un pro des SGBD.. soyez gentils

[pachot]

Bonjour,

Bj'ai l'impression de découvrir ici une limite des bases de données.

Une limite ? Bon au contraire. Pas besoin d'un SGBD pour gérer des données sans aucune structure. Il y a des produits comme BerkeleyDB pour cela.

Mais souvent, on attend d'un SGBD qu'il véréfie les types de données, leur intégrité, etc. Le code qui va lire ces données doit de toute façon avoir une idée de ce qu'il y a dedans non ? On affiche pas de la même manière un libellé, un montant, une quantité...
Donc le fait d'avoir des données structurées dès qu'elles sont saisies permet de garantir que ces données seront utilisables par la suite.

Un exemple, si tu acceptes n'importe quoi comme attribut de produit, je peux rentrer une voiture avec les attributs suivants: nombre_roues=12 , couleur='pastel', prix='250' (sans préciser la devise), reponse='42'.
Que vas-tu faire de cette information ?

Si certains attributs sont si dynamiques, ils peuvent peut-être être stockés en XML. Mais les attributs sur lesquels tu veux avoir des traitements (recherche, calculs) il seront mieux dans des colonnes relationnelles.

Cordialement,
Franck.