Discussion :

[ijbdev]

Bonjour a tous,

je travaille sur un site de e-commerce qui possede un module de gestion de liste, le principe est le suivant: le client peut sauvegarder une selection d'article placés dans le panier pour pouvoir les reconsulter par la suite, fonction utile pour les commandes recurrentes ou pour les comparatifs de prix.

la gestion des liste exploite deux tables de la base de données, la premiere permet de retrouver l'id du client,son type(particulier, entreprise, etc...) l'id de la liste(clé primaire) et son nom.
la seconde permet de retrouver les produits contenus dans la liste, les champs sont les suivants: l'id de la liste(celui de la premiere table), celui du produit, sa quantite et son type.
Donc si le client place 3 produits il y aura autant d'entrées dans la table en question. Cette seconde table est aussi dotée d'une cle primaire auto-incremente qui apparemment ne sert a rien puisque la table de sert qu'a recuperer les articles contenus dans une liste.
je n'utilise que l'id de de liste de la premiere table pour recupere les references des produits dans la seconde.
je m'interroge a la fois sur la pertinence du modele et sur la raison de cette cle.

merci d'avance pour vos eclaircissements.

[CinePhil]

Effectivement, cette clé primaire auto_incrémentée est une erreur de conception !

En MCD, on peut dessiner la relation suivante :
Liste -1,n----Contenir----0,n- Produit

La seconde table dont tu parles est donc la table issue de la relation Contenir. Sa clé primaire devrait être composée des identifiants de la liste et du produit, en tant que clé étrangère.

Les tables :
Liste (L_Id, L_IdClient...)
Produit (P_Id, P_Nom...)
Contenir (C_IdListe, C_IdProduit, C_Quantite...)

A moins que tu aies mis un index UNIQUE sur le couple (C_IdListe, C_IdProduit), le fait d'avoir mis une clé primaire auto-incrémentée n'interdit pas à un produit de se retrouver deux fois sur la même liste. Alors qu'avec la clé primaire double, cette interdiction est automatique.

[ijbdev]

Merci de votre reponse,
En fait il n'y a pas de fonction permettant d'actualiser la liste, il est donc impossible qu'un meme produit se retrouve deux fois avec un meme id de liste dans la seconde table,( lorsqu'un meme produit est commandé en plusieurs exemplaires la variable quantite est automatiquement actualisée dans le panier et la liste est enregistrée à partir de ce dernier).

Le fait d'utiliser une table issue d'une association me parait plus logique mais le moteur de la base MySQL est MyISAM, lequel interdit l'usage de cles etrangeres, apparemment ce choix provient du fait que la base sur laquelle je travaille est exploitée par plusieurs dizaines de sites et que l'innodb ralentirait les acces.

Je serais curieux de connaitre votre opinion a ce propos, et ma question initiale reste donc entiere.

[CinePhil]

Le fait d'utiliser une table issue d'une association me parait plus logique mais le moteur de la base MySQL est MyISAM, lequel interdit l'usage de cles etrangeres,

Le moteur MyISAM n'interdit pas le concept de l'utilisation de clés étrangères !
C'est seulement que les instructions relatives aux contraintes de clés étrangères sont ignorées par le système.
Mais rien n'interdit d'avoir une modélisation correcte avec la clé primaire double comme je l'ai indiqué dans mon premier message. Ensuite, c'est au logiciel utilisateur de remplacer le mécanisme des clés étrangères, ce qui conduit parfois à des données mortes lorsque c'est mal implémenté et qu'on supprime des données.

Quant à la raison de la non utilisation du moteur InnoDB, sans monitoring des performances, impossible à dire. Les raisons sont peut-être tout autres et seul le DBA peut le dire.

[ijbdev]

Merci beaucoup pour vos explications CinePHIL.
Comme je m'occupe du logiciel utilisateur j'essaierai de revenir avec un script de controle des listes efficace pour gerer les effacements en cascade.
Bonne journée.