Conseil d'amelioration PHP/Mysql
Fermé
poulap
-
14 avril 2010 à 16:39
kij_82 Messages postés 4088 Date d'inscription jeudi 7 avril 2005 Statut Contributeur Dernière intervention 30 septembre 2013 - 26 avril 2010 à 13:12
kij_82 Messages postés 4088 Date d'inscription jeudi 7 avril 2005 Statut Contributeur Dernière intervention 30 septembre 2013 - 26 avril 2010 à 13:12
A voir également:
- Conseil d'amelioration PHP/Mysql
- Easy php - Télécharger - Divers Web & Internet
- Mysql download - Télécharger - Bases de données
- Get_magic_quotes_gpc php 8 ✓ - Forum PHP
- Phpmyadmin a tenté de se connecter au serveur mysql, et le serveur a rejeté la connexion. merci de vérifier les valeurs de host, username et password dans la configuration et de s'assurer qu'elles correspondent aux informations fournies par l'administrateur du serveur mysql. ✓ - Forum PHP
- Bouton php - Forum PHP
29 réponses
J'ai conçu le MCD et le MLD correspondant :
MCD : http://www.monsterup.com/image.php?url=upload/1271673258948.png
MLD :
CLIENT (CodeClient, Nom, Adresse, CodePostal, Ville, Tel)
COMMANDE (Com_id, Prix_total_calculé, #CodeClient)
OPTION (Option_id, Option_value, Option_value_name, #Com_id)
INCLUT (#Com_id, #Products_id, Quantité)
PRODUIT (Products_id, Prix, Vendable(true/false))
COMPOSE (Master_id, Slave_id, Obligatoire, Nombre)
Je pense que les modèles sont corrects ?
Maintenant il faut que je m'interesse à la création des tables et a son incorporation propre dans la BD existante (phpMySQL).
Faut-il mieux que je le code a la main en SQL, ou que j'utilise "l'interface graphique" ?
Je vais éditer mon post au fur et a mesure que j'avancerai dans la conception des tables ...
MCD : http://www.monsterup.com/image.php?url=upload/1271673258948.png
MLD :
CLIENT (CodeClient, Nom, Adresse, CodePostal, Ville, Tel)
COMMANDE (Com_id, Prix_total_calculé, #CodeClient)
OPTION (Option_id, Option_value, Option_value_name, #Com_id)
INCLUT (#Com_id, #Products_id, Quantité)
PRODUIT (Products_id, Prix, Vendable(true/false))
COMPOSE (Master_id, Slave_id, Obligatoire, Nombre)
Je pense que les modèles sont corrects ?
Maintenant il faut que je m'interesse à la création des tables et a son incorporation propre dans la BD existante (phpMySQL).
Faut-il mieux que je le code a la main en SQL, ou que j'utilise "l'interface graphique" ?
Je vais éditer mon post au fur et a mesure que j'avancerai dans la conception des tables ...
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 14/04/2010 à 17:50
Modifié par kij_82 le 14/04/2010 à 17:50
Bonjour,
Je n'ai pas regardé le site, mais concernant ton problème d'autogestion du stock sur les produits existants à l'intérieur d'autres produits, il suffirait d'ajouter une table dans la base de donnée chargée de faire le lien entre "type de produit".
Une simple table avec deux champs qui constitue la clef primaire de cette table.
Le premier champ serait l'ID du produit englobant les autres.
Le second champ serait l'ID d'un produit englobé dans un autre.
En ce qui concerne la recherche, c'est relativement simple, une fois que tu as l'ID du produit englobant, tu fais une recherche dans cette nouvelle table pour connaitre l'ensemble des ID lié à ce produit englobant (recherche sur le premier champ donc)
Pour aller plus loin et récupérer le nombre de produit englobé pour un produit englobant donné, il suffit d'effectuer une requête SQL à la fois sur cette nouvelle table, et sur celle des produits afin de récupérer le stock (et d'autres informations si nécessaire) de chacun des produits englobés.
Ainsi il sera possible de savoir lors d'un achat / réservation si l'ensemble des produits englobés est disponible, de même que mettre à jour ce stock si l'achat est validé.
Attention à ne pas oublier qu'un produit englobé peut-être lui-même englobant... et donc faire une recherche pseudo récursive sur les objets englobants. On voit alors qu'il sera nécessaire de connaitre dans la base de données (d'une façon ou d'une autre) si un objet contient d'autres objets avant même de faire une recherche des objets englobés de cet objet (pour avoir de moins gros traitements). Ceci peut passé par une propriété à mettre à jour dans la table des produits par exemple, un booléen sera plus commode.
Alors bien sur, puisque tu pars d'une base de données existante, le plus dur ne sera pas de mettre en place les scripts d'autogestion du stock existant sur ces produits / sous produits. Le vrai travail sera d'entrer manuellement (ou via une interface de gestion accessible via profil sur le site lui-même) le lien entre chaque produit englobant / englobé.
Le choix de mettre en place une interface graphique de mise à jour de ces liens parait judicieux, puisqu'elle servira en premier lieu à mettre en place ces liens, mais aussi à les modifier / en créer de nouveau à l'avenir.
Reste à toi de mettre en place cette solution, ou de voir s'il en existe de plus commode.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
Je n'ai pas regardé le site, mais concernant ton problème d'autogestion du stock sur les produits existants à l'intérieur d'autres produits, il suffirait d'ajouter une table dans la base de donnée chargée de faire le lien entre "type de produit".
Une simple table avec deux champs qui constitue la clef primaire de cette table.
Le premier champ serait l'ID du produit englobant les autres.
Le second champ serait l'ID d'un produit englobé dans un autre.
En ce qui concerne la recherche, c'est relativement simple, une fois que tu as l'ID du produit englobant, tu fais une recherche dans cette nouvelle table pour connaitre l'ensemble des ID lié à ce produit englobant (recherche sur le premier champ donc)
Pour aller plus loin et récupérer le nombre de produit englobé pour un produit englobant donné, il suffit d'effectuer une requête SQL à la fois sur cette nouvelle table, et sur celle des produits afin de récupérer le stock (et d'autres informations si nécessaire) de chacun des produits englobés.
Ainsi il sera possible de savoir lors d'un achat / réservation si l'ensemble des produits englobés est disponible, de même que mettre à jour ce stock si l'achat est validé.
Attention à ne pas oublier qu'un produit englobé peut-être lui-même englobant... et donc faire une recherche pseudo récursive sur les objets englobants. On voit alors qu'il sera nécessaire de connaitre dans la base de données (d'une façon ou d'une autre) si un objet contient d'autres objets avant même de faire une recherche des objets englobés de cet objet (pour avoir de moins gros traitements). Ceci peut passé par une propriété à mettre à jour dans la table des produits par exemple, un booléen sera plus commode.
Alors bien sur, puisque tu pars d'une base de données existante, le plus dur ne sera pas de mettre en place les scripts d'autogestion du stock existant sur ces produits / sous produits. Le vrai travail sera d'entrer manuellement (ou via une interface de gestion accessible via profil sur le site lui-même) le lien entre chaque produit englobant / englobé.
Le choix de mettre en place une interface graphique de mise à jour de ces liens parait judicieux, puisqu'elle servira en premier lieu à mettre en place ces liens, mais aussi à les modifier / en créer de nouveau à l'avenir.
Reste à toi de mettre en place cette solution, ou de voir s'il en existe de plus commode.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
Merci pour ta réponse...
Mais on m'a déconseillé de créer de nouvelles tables.
Mais plutôt déclarer un pack virtuel qui est un produit qui contient d'autre produits.
Une chambre est un produit qui contient d'autre produits (lit, commode, ...)
Avec une relation comme celle ci :
pack_id INT REFERENCES products( product_id ) ON DELETE CASCADE
product_id INT REFERENCES products( product_id ) ON DELETE CASCADE
Une sorte de graphe récursif...Donc utiliser du php en récursif ..
Mais je vois pas comment utiliser cette méthode en pratique..
Quelqu'un aurait un exemple a me montrer, j'arrive pas a démarré... je patauge :/
Merci
Mais on m'a déconseillé de créer de nouvelles tables.
Mais plutôt déclarer un pack virtuel qui est un produit qui contient d'autre produits.
Une chambre est un produit qui contient d'autre produits (lit, commode, ...)
Avec une relation comme celle ci :
pack_id INT REFERENCES products( product_id ) ON DELETE CASCADE
product_id INT REFERENCES products( product_id ) ON DELETE CASCADE
Une sorte de graphe récursif...Donc utiliser du php en récursif ..
Mais je vois pas comment utiliser cette méthode en pratique..
Quelqu'un aurait un exemple a me montrer, j'arrive pas a démarré... je patauge :/
Merci
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 15/04/2010 à 11:29
Modifié par kij_82 le 15/04/2010 à 11:29
Ok je vois.
Mais dans ce cas, cela veut forcément dire que ta base de données comprend déjà les liens entre produits. Si oui, alors tu pourra ajouter les contraintes de DELETE ON CASCADE toi même.
Si ce n'est pas le cas, tu vas être - je crois - obliger de modifier un minimum ta base de données pour gérer ces contraintes référentielles.
Tu peux t'inspirer de ce qu'il est montré / dit dans cette discussion:
https://forums.commentcamarche.net/forum/affich-844296-sql-faire-une-suppresion-en-cascade
Une fois que tu auras mise cela en place, pas besoin d'avoir du PHP en récursif, dès que tu vas delete un produits composé d'autres produits, tous les sous produits rattaché à ce produit seront également delete. C'est le gestionnaire de la BDD qui s'en occupe.
Mais dans ce cas, cela veut forcément dire que ta base de données comprend déjà les liens entre produits. Si oui, alors tu pourra ajouter les contraintes de DELETE ON CASCADE toi même.
Si ce n'est pas le cas, tu vas être - je crois - obliger de modifier un minimum ta base de données pour gérer ces contraintes référentielles.
Tu peux t'inspirer de ce qu'il est montré / dit dans cette discussion:
https://forums.commentcamarche.net/forum/affich-844296-sql-faire-une-suppresion-en-cascade
Une fois que tu auras mise cela en place, pas besoin d'avoir du PHP en récursif, dès que tu vas delete un produits composé d'autres produits, tous les sous produits rattaché à ce produit seront également delete. C'est le gestionnaire de la BDD qui s'en occupe.
Il faut donc que je crée d'avance tout les différents packs avec les produits correspondant.
Donc dans ma table produit je crée un nouveau champs pack qui pour chaque pack a des liens (clefs externes) vers les produits qui sont contenus dans ce pack.
Et avec la condition DELETE ON CASCADE !
Cela suffit ?
Il n'y a pas une méthode plus générale ? parce qu'il y a plus ou moins beaucoup de pack différent, et c'est surtout qu'après la solution devras être implémenté pour d'autre sorte de pack !
Donc dans ma table produit je crée un nouveau champs pack qui pour chaque pack a des liens (clefs externes) vers les produits qui sont contenus dans ce pack.
Et avec la condition DELETE ON CASCADE !
Cela suffit ?
Il n'y a pas une méthode plus générale ? parce qu'il y a plus ou moins beaucoup de pack différent, et c'est surtout qu'après la solution devras être implémenté pour d'autre sorte de pack !
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
15 avril 2010 à 12:58
15 avril 2010 à 12:58
Ben de toute manière il n'y a pas de solution magique qui fera tout sans rien faire :)
Si la base de données n'est pas préparée à ce genre de traitement (que ce soit via ces liens ou une nouvelle table), je vois mal comment faire ce qu'il t'est demandé de faire.
Si la base de données n'est pas préparée à ce genre de traitement (que ce soit via ces liens ou une nouvelle table), je vois mal comment faire ce qu'il t'est demandé de faire.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Il subsiste un problème, car les packs ne sont pas totalement fixe.
Exemple : le client choisit la chambre de bébé GLOSSY
il donc par défaut la commode 3 tiroirs mais il doit choisir s'il prend l'étagère ou non. Et s'il prend le lit 60-120 ou le lit 70-140 !
Donc je dois créer en prévision tous les packs possibles et vérifier ensuite lors du paiement a quel pack cela correspond ? avant de pouvoir faire la recherche...
Bon finalement j'ai réfléchit à une autre solution :
garder la table produit en lien avec une table Pack Produit (comme tu l'a suggéré) avec l'id pack et l'id produit ET aussi id option
la table pack serait en lien avec une table Pack qui contient toutes les informations sur le pack (prix, ...)
et enfin une table Option qui contient les différentes options possibles et qui fait le lien entre produit et Pack.
Produit
------------
id_produit
...
Pack Produit
-----------------
id_pack
id_produit
id_option
Pack
-----------
référence
prix
...
Option
-------------
lit 60-120
lit 70-140
...
Un tel modèle serait t'il fonctionnel ?
Exemple : le client choisit la chambre de bébé GLOSSY
il donc par défaut la commode 3 tiroirs mais il doit choisir s'il prend l'étagère ou non. Et s'il prend le lit 60-120 ou le lit 70-140 !
Donc je dois créer en prévision tous les packs possibles et vérifier ensuite lors du paiement a quel pack cela correspond ? avant de pouvoir faire la recherche...
Bon finalement j'ai réfléchit à une autre solution :
garder la table produit en lien avec une table Pack Produit (comme tu l'a suggéré) avec l'id pack et l'id produit ET aussi id option
la table pack serait en lien avec une table Pack qui contient toutes les informations sur le pack (prix, ...)
et enfin une table Option qui contient les différentes options possibles et qui fait le lien entre produit et Pack.
Produit
------------
id_produit
...
Pack Produit
-----------------
id_pack
id_produit
id_option
Pack
-----------
référence
prix
...
Option
-------------
lit 60-120
lit 70-140
...
Un tel modèle serait t'il fonctionnel ?
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
15 avril 2010 à 14:35
15 avril 2010 à 14:35
Dans cet exemple:
On voit qu'un lien (clé étrangère) sur un champ d'une autre table, avec en plus une contrainte de suppression en cascade lorsqu'un item qui y est lié est supprimé.
Il te faut faire la même chose, en prévoyant effectivement à l'avance les liens à établir.
Libre ensuite lors de la création d'un produit (choisi par le client), d'y lier ou non (remplir les clef étrangères) concernant les sous produits qu'il aura choisi ou non.
C'est bien ça que tu dois faire non ?
CREATE TABLE piForum ( foID NUMERIC(4) NOT NULL PRIMARY KEY, foLoID NUMERIC(4) NOT NULL, foMessage VARCHAR(255), foEtoiles NUMERIC(1), INDEX ind_LoID (foLoID), CONSTRAINT fkForum FOREIGN KEY (foLoID) REFERENCES piLogiciels(loID) ON DELETE CASCADE ) TYPE=INNODB;
On voit qu'un lien (clé étrangère) sur un champ d'une autre table, avec en plus une contrainte de suppression en cascade lorsqu'un item qui y est lié est supprimé.
Il te faut faire la même chose, en prévoyant effectivement à l'avance les liens à établir.
Libre ensuite lors de la création d'un produit (choisi par le client), d'y lier ou non (remplir les clef étrangères) concernant les sous produits qu'il aura choisi ou non.
C'est bien ça que tu dois faire non ?
Je suis pour l'instant à essayer de mettre en forme un MCD qui tient la route et qui permet de gérer le problème de stock !
Et j'aimerai bien avoir un avis ce que j'ai fait, parce que c'est pas bien clair encore et mon MCD me semble bancale :
https://openclassrooms.com/forum/sujet/mcd-d-un-probleme-epineux-69889
J'ai expliqué ma démarche...
Vous remercie encore =)
Et j'aimerai bien avoir un avis ce que j'ai fait, parce que c'est pas bien clair encore et mon MCD me semble bancale :
https://openclassrooms.com/forum/sujet/mcd-d-un-probleme-epineux-69889
J'ai expliqué ma démarche...
Vous remercie encore =)
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
16 avril 2010 à 11:47
16 avril 2010 à 11:47
Ok, donc si au final tu es reparti sur la refonte de ton système d'info, je pense qu'une simple table 'produit' avec deux tables de relation 'options' et 'obligation' sur la table produit (relation père-fils sur la même table donc), tu dois pouvoir remédier à ton problème.
Comme le dis si bien Lord Casque Noir sur l'autre site, il faut bien faire attention au fait qu'un Pack n'est rien de concret, et ne dois donc pas être modéliser. Un pack n'est rien d'autre qu'un produit qui en contient d'autres, obligatoires ou facultatifs.
Au fanal, tu aurais donc ceci:
Produit (id_produit, etc..), Obligatoire (id_produit (master), id_produit (slave), Optionnel (id_produit (master), id_produit (slave).
Je ne parle pas des éventuelles autres tables de description des produits, etc. Je te laisse le libre choix de tout mettre dans une seule ou séparer pour alléger les recherche qui auront lieu sur la table produit (certainement plus nombreuses que les requêtes de récupération des description des produits même)
De mon avis, des tables pour modéliser les relations entre produits sont bien pour le fait que tu peux avoir (ou non) plusieurs produits obligatoire ou optionnel pour un autre produit.
Une fois cette base de données mise en place, tu devra alors créer les scripts PHP de mise à jour. (création, ajout de produits ou de leur relation entre eux, suppression, etc.) Certains de ces scripts boucleront leur recherche sur les "sous produits" de chaque produit ainsi récupérer - si des relations existent uniquement.
Comme le dis si bien Lord Casque Noir sur l'autre site, il faut bien faire attention au fait qu'un Pack n'est rien de concret, et ne dois donc pas être modéliser. Un pack n'est rien d'autre qu'un produit qui en contient d'autres, obligatoires ou facultatifs.
Au fanal, tu aurais donc ceci:
Produit (id_produit, etc..), Obligatoire (id_produit (master), id_produit (slave), Optionnel (id_produit (master), id_produit (slave).
Je ne parle pas des éventuelles autres tables de description des produits, etc. Je te laisse le libre choix de tout mettre dans une seule ou séparer pour alléger les recherche qui auront lieu sur la table produit (certainement plus nombreuses que les requêtes de récupération des description des produits même)
De mon avis, des tables pour modéliser les relations entre produits sont bien pour le fait que tu peux avoir (ou non) plusieurs produits obligatoire ou optionnel pour un autre produit.
Une fois cette base de données mise en place, tu devra alors créer les scripts PHP de mise à jour. (création, ajout de produits ou de leur relation entre eux, suppression, etc.) Certains de ces scripts boucleront leur recherche sur les "sous produits" de chaque produit ainsi récupérer - si des relations existent uniquement.
Ce modèle me parait effectivement plus adapté a la solution et même peut être plus facile a implémenté.
Par contre comment faire pour la table Optionnel car :
Le client a le choix entre plusieurs options pour un seul produit master.
ex : une chambre truc a plusieurs options : un lit 60-120 OU un lit 70-140, une commode 2 tiroirs OU une commode 3 tiroirs, ...
il faut répertorier les différentes options pour un produit master ? ou bien ? et après comment savoir ce qui a été choisi et faire le lien avec la table produit pour mettre la quantité a jour ?
Car pour la table Obligatoire je vois bien vu que pour un produit master, il y aura un produit slave ou plusieurs mais qui ne changerons pas !
Par contre comment faire pour la table Optionnel car :
Le client a le choix entre plusieurs options pour un seul produit master.
ex : une chambre truc a plusieurs options : un lit 60-120 OU un lit 70-140, une commode 2 tiroirs OU une commode 3 tiroirs, ...
il faut répertorier les différentes options pour un produit master ? ou bien ? et après comment savoir ce qui a été choisi et faire le lien avec la table produit pour mettre la quantité a jour ?
Car pour la table Obligatoire je vois bien vu que pour un produit master, il y aura un produit slave ou plusieurs mais qui ne changerons pas !
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 16/04/2010 à 14:17
Modifié par kij_82 le 16/04/2010 à 14:17
Ok,
ce qu'il est alors peut-être possible de faire, pour distinguer tous les produits qui ont des spécificités (numérique ou dimensionnelles pour les exemples des lits et tiroirs par exemple), tu peux faire une table qui identifie ces spécificités.
Exemple : si l'on parle des lits, créer une table dimension qui répertorie (via ses valeurs) la liste des dimensions existantes pour un lit.
Par contre on voit vite que plus tu as de produit divers qui ont des propriétés différentes, et plus il faudrait de table pour les répertorier.
La vraie question à se poser à ce moment c'est : Ais-je un besoin vital de représenter ces propriétés, pour la gestion de mon stock / de mon application ?
Dans ton cas la réponse est oui : puisqu'il faut pouvoir choisir les dimensions d'un lit, et surtout, lorsque tu commande de nouveau lit, c'est avec des dimensions particulières, tous les lits n'ont pas les mêmes, et ce n'est pas le lit aux dimensions B qui doit être commandé lorsque le lit aux dimensions A est en ruptures de stock.
Dans ton cas, la meilleure option est de lister sur les produits, l'ensemble des propriétés différentes que peuvent avoir les produits (couleur, dimensions, etc.)
Attention : certaines propriétés peuvent être "résolue" en temps que produits, mais produits non vendable s'il ne sont pas proposé au détail.
Les tiroirs par exemple, c'est un produit qui compose les meubles. Reste alors à intégrer une propriété booléen dans la table produit pour indiquer si le produit est vendable ou non, et si oui, une propriété pour son prix (s'il y a lieu d'intégrer un prix aux produits)
D'ailleurs cette question de prix est primordiale pour la conception : est ce que le prix des produits varient en fonction de leur propriétés spécifiques (couleur par exemple, et dimensions). Certainement. Il faut donc réfléchir à comment intégrer cette notion de prix qui varie selon les critères sélectionnés.
Par exemple, un produit pourrait avoir une propriété "prix" dans sa table, mais aussi une propriété "prix" dans la table de liaison entre la table "produit" et la table "couleur" par exemple.
Ainsi, le calcul automatique du prix selon les critères sélectionnés peut être plus facilement calculé via le script PHP qui effectuera les requêtes SQL de sélection.
Toutes ces questions (et il y en a certainement d'autres à se poser) sont à étudier par rapport au "cahier des charges" donné par le "client". S'il n'y en a pas, c'est à toi de poser toutes ces questions dans le but de cerné plus rapidement les différentes difficultés / les différents besoin pour la conception.
Voilà, j'espère t'avoir donné les idées qui te permettront de mettre en place cette gestion de stock / prix / lien entre les différents produits.
Si tu as d'autres questions.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
ce qu'il est alors peut-être possible de faire, pour distinguer tous les produits qui ont des spécificités (numérique ou dimensionnelles pour les exemples des lits et tiroirs par exemple), tu peux faire une table qui identifie ces spécificités.
Exemple : si l'on parle des lits, créer une table dimension qui répertorie (via ses valeurs) la liste des dimensions existantes pour un lit.
Par contre on voit vite que plus tu as de produit divers qui ont des propriétés différentes, et plus il faudrait de table pour les répertorier.
La vraie question à se poser à ce moment c'est : Ais-je un besoin vital de représenter ces propriétés, pour la gestion de mon stock / de mon application ?
Dans ton cas la réponse est oui : puisqu'il faut pouvoir choisir les dimensions d'un lit, et surtout, lorsque tu commande de nouveau lit, c'est avec des dimensions particulières, tous les lits n'ont pas les mêmes, et ce n'est pas le lit aux dimensions B qui doit être commandé lorsque le lit aux dimensions A est en ruptures de stock.
Dans ton cas, la meilleure option est de lister sur les produits, l'ensemble des propriétés différentes que peuvent avoir les produits (couleur, dimensions, etc.)
Attention : certaines propriétés peuvent être "résolue" en temps que produits, mais produits non vendable s'il ne sont pas proposé au détail.
Les tiroirs par exemple, c'est un produit qui compose les meubles. Reste alors à intégrer une propriété booléen dans la table produit pour indiquer si le produit est vendable ou non, et si oui, une propriété pour son prix (s'il y a lieu d'intégrer un prix aux produits)
D'ailleurs cette question de prix est primordiale pour la conception : est ce que le prix des produits varient en fonction de leur propriétés spécifiques (couleur par exemple, et dimensions). Certainement. Il faut donc réfléchir à comment intégrer cette notion de prix qui varie selon les critères sélectionnés.
Par exemple, un produit pourrait avoir une propriété "prix" dans sa table, mais aussi une propriété "prix" dans la table de liaison entre la table "produit" et la table "couleur" par exemple.
Ainsi, le calcul automatique du prix selon les critères sélectionnés peut être plus facilement calculé via le script PHP qui effectuera les requêtes SQL de sélection.
Toutes ces questions (et il y en a certainement d'autres à se poser) sont à étudier par rapport au "cahier des charges" donné par le "client". S'il n'y en a pas, c'est à toi de poser toutes ces questions dans le but de cerné plus rapidement les différentes difficultés / les différents besoin pour la conception.
Voilà, j'espère t'avoir donné les idées qui te permettront de mettre en place cette gestion de stock / prix / lien entre les différents produits.
Si tu as d'autres questions.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
Ok,
Bon j'ai mis au point le MCD qui décrit ta solution... je crois =)
J'ai l'impression que ça peut marcher, même si il manque peut-être quelques détails... dis moi si ça convient stp.
Merci en tout cas bcp pour ton aide.
http://www.monsterup.com/image.php?url=upload/1271421726663.jpg
id_option correspond a un numéro qui a comme option_name associé :
1 - couleur
2 - taille de lit
ect
option_values est le numéro de l'option réel associé a option_value_name :
1 - rose
2 - bleu
...
donc par exemple le lit :
option_id option_name option_values option_values_name
2 taille du lit 1 60-120
Enfin une table OPTION TO PRODUIT qui fera correspondre l'option_value au products_id
Je me demande si les liens se feront bien, et quelles contrainte il faudra mettre. Mais j'ai l'impression que c'est sur la bonne voie....
Bon j'ai mis au point le MCD qui décrit ta solution... je crois =)
J'ai l'impression que ça peut marcher, même si il manque peut-être quelques détails... dis moi si ça convient stp.
Merci en tout cas bcp pour ton aide.
http://www.monsterup.com/image.php?url=upload/1271421726663.jpg
id_option correspond a un numéro qui a comme option_name associé :
1 - couleur
2 - taille de lit
ect
option_values est le numéro de l'option réel associé a option_value_name :
1 - rose
2 - bleu
...
donc par exemple le lit :
option_id option_name option_values option_values_name
2 taille du lit 1 60-120
Enfin une table OPTION TO PRODUIT qui fera correspondre l'option_value au products_id
Je me demande si les liens se feront bien, et quelles contrainte il faudra mettre. Mais j'ai l'impression que c'est sur la bonne voie....
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 16/04/2010 à 15:36
Modifié par kij_82 le 16/04/2010 à 15:36
Oui, il est effectivement possible de faire comme cela. Mais c'est vrai que ça complique énormément le système d'information et surtout sa bonne gestion.
J'ai repensé à un exemple concret de ce que tu es en train de mettre en place : Ikea. Es-tu déjà allé dans un magasin Idea ?
Si ce n'est pas le cas, explication : sur chaque produit vendable là-bas tu as une référence distincte. Et les caractéristiques rentrent en compte dans le produit lui-même. Exemple : un meuble noir avec trois tiroir aura une référence (ce qui correspond à ton ID dans ton cas) différente d'un meuble noir/blanc/etc. avec deux tiroirs.
Ce modèle permet de simplifier beaucoup la gestion du stock.
Appliquer à ce que tu souhaite faire, cela veut dire qu'il faut:
- lister les différentes distinction d'un produit (couleur, dimensions, etc.) et les incorporer à la table 'produit'
- avoir juste un table qui fait le lien entre les produits à coté.
Ainsi, ton MCD reste simple à gérer, mais représentera peut-être un poil plus de données dans ta base (et encore, à ce niveau là je ne suis même pas sûr !)
MCD:
PRODUIT
- id (clé primaire de la table)
...
- prix
- vendable (true/false)
COMPOSE (table de lien)
- id master
- id slave (la réunion des deux ID composent la clé primaire de la table)
...
- mandatory (obligatoire, true/false)
- number (nombre de produit slave qui compose le produit master, pour les tiroirs par exemple)
Voilà, deux tables, simple, efficace je pense.
Ca c'est pour représenter les liens entre les différents produits, et qui te permettra donc d'en gérer le stock, la modularité pour présenter les choix aux clients.
Si tu souhaites enregistrer les choix des clients, il te faudra faire une nouvelle table, 'commande' par exemple, avec ses propriétés (id, prix total calculé par rapport à ce qui est commandé), ainsi qu'une table de relation entre cette commande et l'ensemble des produits regroupés sous cette commande, qu'on nommera 'inclut' par exemple et qui comprendra en propriété l'identifiant de la commande et celui de du produit, le nombre commandé de ce produit et d'autres choses si tu en as besoin.
Ainsi, avec cette gestion des commandes, tu pourras facilement décroitre ton stock actuel par rapport à ce qui est commandé / acheté, ou inversement l'augmenter par rapport à ce qui avait été commandé s'il y a annulation de la commande. Et ça fait toujours un inventaire des commandes pour faire des statistiques sur les produits les plus achetés, etc. (ça peut toujours intéressé la boite pour laquelle tu fais ça)
Idem par la suite, tu pourra inclure une table pour les clients, ainsi qu'une autre pour lier les clients à leur commande (si c'est le veux de gestion de la boite bien sur, sinon ça ne sert à rien). Comme ça des profils pourront être plus ou moins dressés pour proposer des choses en guise de publicité aux clients enregistrés.
Pour en revenir au problème premier (le stock), je serais toi, j'opterais pour le MCD à deux tables, plus simple à gérer. Mais à choisir selon les choix de gestion de ta boite (si elle souhaite réellement gérer des couleurs ou des dimensions, ce qui m'étonnerai puisque ce n'est pas ça qui créé le chiffre d'affaire mais bel et bien le produit lui-même - non ses caractéristiques)
Désolé si mes dires passent d'un choix à l'autre, je découvre en même temps ce dont tu as réellement besoin, etc. ^^
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
J'ai repensé à un exemple concret de ce que tu es en train de mettre en place : Ikea. Es-tu déjà allé dans un magasin Idea ?
Si ce n'est pas le cas, explication : sur chaque produit vendable là-bas tu as une référence distincte. Et les caractéristiques rentrent en compte dans le produit lui-même. Exemple : un meuble noir avec trois tiroir aura une référence (ce qui correspond à ton ID dans ton cas) différente d'un meuble noir/blanc/etc. avec deux tiroirs.
Ce modèle permet de simplifier beaucoup la gestion du stock.
Appliquer à ce que tu souhaite faire, cela veut dire qu'il faut:
- lister les différentes distinction d'un produit (couleur, dimensions, etc.) et les incorporer à la table 'produit'
- avoir juste un table qui fait le lien entre les produits à coté.
Ainsi, ton MCD reste simple à gérer, mais représentera peut-être un poil plus de données dans ta base (et encore, à ce niveau là je ne suis même pas sûr !)
MCD:
PRODUIT
- id (clé primaire de la table)
...
- prix
- vendable (true/false)
COMPOSE (table de lien)
- id master
- id slave (la réunion des deux ID composent la clé primaire de la table)
...
- mandatory (obligatoire, true/false)
- number (nombre de produit slave qui compose le produit master, pour les tiroirs par exemple)
Voilà, deux tables, simple, efficace je pense.
Ca c'est pour représenter les liens entre les différents produits, et qui te permettra donc d'en gérer le stock, la modularité pour présenter les choix aux clients.
Si tu souhaites enregistrer les choix des clients, il te faudra faire une nouvelle table, 'commande' par exemple, avec ses propriétés (id, prix total calculé par rapport à ce qui est commandé), ainsi qu'une table de relation entre cette commande et l'ensemble des produits regroupés sous cette commande, qu'on nommera 'inclut' par exemple et qui comprendra en propriété l'identifiant de la commande et celui de du produit, le nombre commandé de ce produit et d'autres choses si tu en as besoin.
Ainsi, avec cette gestion des commandes, tu pourras facilement décroitre ton stock actuel par rapport à ce qui est commandé / acheté, ou inversement l'augmenter par rapport à ce qui avait été commandé s'il y a annulation de la commande. Et ça fait toujours un inventaire des commandes pour faire des statistiques sur les produits les plus achetés, etc. (ça peut toujours intéressé la boite pour laquelle tu fais ça)
Idem par la suite, tu pourra inclure une table pour les clients, ainsi qu'une autre pour lier les clients à leur commande (si c'est le veux de gestion de la boite bien sur, sinon ça ne sert à rien). Comme ça des profils pourront être plus ou moins dressés pour proposer des choses en guise de publicité aux clients enregistrés.
Pour en revenir au problème premier (le stock), je serais toi, j'opterais pour le MCD à deux tables, plus simple à gérer. Mais à choisir selon les choix de gestion de ta boite (si elle souhaite réellement gérer des couleurs ou des dimensions, ce qui m'étonnerai puisque ce n'est pas ça qui créé le chiffre d'affaire mais bel et bien le produit lui-même - non ses caractéristiques)
Désolé si mes dires passent d'un choix à l'autre, je découvre en même temps ce dont tu as réellement besoin, etc. ^^
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
T'es un Dieu, j'ai bien compris je pense comment modéliser tout ça... je vais faire ça au propre.
Je viens de me rendre compte qu'il faut que j'ajoute une table Option lié a la table Commande pour les options de livraisons, ...
Par contre la table Produit en lien avec la table Compose est vraiment bien pensé.
Je te remercie vraiment sincèrement pour ton aide précieuse...
Je risque de revenir poser des questions quand j'aurais bien mit au propre ce modèle..
Mais ça sera après le weekend =)
Merci encore, kij_82.
Tibo
Je viens de me rendre compte qu'il faut que j'ajoute une table Option lié a la table Commande pour les options de livraisons, ...
Par contre la table Produit en lien avec la table Compose est vraiment bien pensé.
Je te remercie vraiment sincèrement pour ton aide précieuse...
Je risque de revenir poser des questions quand j'aurais bien mit au propre ce modèle..
Mais ça sera après le weekend =)
Merci encore, kij_82.
Tibo
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
16 avril 2010 à 17:09
16 avril 2010 à 17:09
Bon week-end et à lundi.
Au passage, si jamais tu n'as pas appris de méthodologie de modélisation, celle que j'utilise couramment est MERISE, petite explication ici:
https://forums.commentcamarche.net/forum/affich-37622101-merise-modele-conceptuel-des-donnees
Et des exercices pratiques:
http://www.sam-mag.com/P53,53,5,55,,,default.aspx
(Bien) Concevoir est l'une des phases les plus importantes dans une application.
Au passage, si jamais tu n'as pas appris de méthodologie de modélisation, celle que j'utilise couramment est MERISE, petite explication ici:
https://forums.commentcamarche.net/forum/affich-37622101-merise-modele-conceptuel-des-donnees
Et des exercices pratiques:
http://www.sam-mag.com/P53,53,5,55,,,default.aspx
(Bien) Concevoir est l'une des phases les plus importantes dans une application.
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 19/04/2010 à 14:02
Modifié par kij_82 le 19/04/2010 à 14:02
Bonjour,
Ton modèle n'est pas bon à un endroit :
La table "compose" n'est pas une entité en soit, mais une relation père-fil sur la table "produit" (un produit lié à un autre via la relation "compose".
Donc par rapport à ton MCD, la relation "est composé" est à supprimer / remplacer par la relation "compose" :
------------| |------------------
PRODUIT | <----- | COMPOSE
-------------| ------>|------------
Désolé pour la médiocrité du schéma, je n'ai pas accès aux sites de hosting depuis où je suis.
Mais sinon le reste est correct, good job.
Pour la création de la base de données, mieux vaut passé par l'interface graphique puisqu'elle est là pour te simplifier la tâche.
Une fois la base créée complètement, exporte ta base de données (structure complètes des tables inclues les drop if exist, etc.. + les données dites "métier")
Les données dites "métier", c'est tout ce qui est mis "en dur" dans la base de données. Dans ton cas par exemple, ce sera les options de commande. Ce n'est pas quelque chose que tu vas créer dynamiquement depuis ton site, mais quelque chose que tu insère dans la base à l'avance, une bonne fois pour toute, et qui te servira dans ton site.
Idem, les produits ne sont à priori pas créer dans ton site mais à la main, où du moins il y en a toute une tripotée qui existent déjà, donc autant les insèrer. De même pour les liens entre produits existants, à créer également avec l'exportation de ta base de données.
Exporter ta base de données au format texte (à sauvegarder dans un fichier donc), ce sera si des fois ta base crash, où du moins l'installation de ton SGBD, tu pourras toujours la recréer à partir de ce fichier de sauvegarde.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
Ton modèle n'est pas bon à un endroit :
La table "compose" n'est pas une entité en soit, mais une relation père-fil sur la table "produit" (un produit lié à un autre via la relation "compose".
Donc par rapport à ton MCD, la relation "est composé" est à supprimer / remplacer par la relation "compose" :
------------| |------------------
PRODUIT | <----- | COMPOSE
-------------| ------>|------------
Désolé pour la médiocrité du schéma, je n'ai pas accès aux sites de hosting depuis où je suis.
Mais sinon le reste est correct, good job.
Pour la création de la base de données, mieux vaut passé par l'interface graphique puisqu'elle est là pour te simplifier la tâche.
Une fois la base créée complètement, exporte ta base de données (structure complètes des tables inclues les drop if exist, etc.. + les données dites "métier")
Les données dites "métier", c'est tout ce qui est mis "en dur" dans la base de données. Dans ton cas par exemple, ce sera les options de commande. Ce n'est pas quelque chose que tu vas créer dynamiquement depuis ton site, mais quelque chose que tu insère dans la base à l'avance, une bonne fois pour toute, et qui te servira dans ton site.
Idem, les produits ne sont à priori pas créer dans ton site mais à la main, où du moins il y en a toute une tripotée qui existent déjà, donc autant les insèrer. De même pour les liens entre produits existants, à créer également avec l'exportation de ta base de données.
Exporter ta base de données au format texte (à sauvegarder dans un fichier donc), ce sera si des fois ta base crash, où du moins l'installation de ton SGBD, tu pourras toujours la recréer à partir de ce fichier de sauvegarde.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
Alors plutôt comme cela :
http://www.monsterup.com/image.php?url=upload/127168216552.png
ça me parait un peu bizarre et je ne vois pas trop ce que ça change...
En tout cas le MLD reste le même non ? le même nombre de tables ?
http://www.monsterup.com/image.php?url=upload/127168216552.png
ça me parait un peu bizarre et je ne vois pas trop ce que ça change...
En tout cas le MLD reste le même non ? le même nombre de tables ?
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 19/04/2010 à 15:42
Modifié par kij_82 le 19/04/2010 à 15:42
Non, tu as deux "liens" entre "produit" et "compose". L'un symbolise le fait qu'un produit soit composé de..., l'autre symbolise le fait qu'un produit compose...
C'est ce qu'on l'on appelle une relation parent-enfant : c'est une relation sur la même entité, avec deux liens ayant chacun un sens, l'un allant de l'entité (ici "produit") vers la relation (ici "compose") et l'autre allant de la relation vers l'entité.
Tu saisie la différence ?
Si tu ne fais qu'un seul lien, comment sais-tu quel produit compose l'autre ? Et inversement ?
Ici pense bien qu'il s'agit uniquement d'un MCD, et non pas de la représentation même de ta base de données.
Dans ta base de données, tu n'auras au final qu'une seule table "compose", avec les deux champs identifiant.
Le fait qu'un identifiant se retrouve sur la première clef (master_id) signifiera qu'il est composé d'un autre produits, le fait qu'il se retrouve sur la seconde (slave_id) clef signifiera qu'il compose un autre produit.
Le MLD ne change pas cela dit, tu as raison sur ce point :) Et c'est bien le MLD qui se rapprochera donc le plus de la représentation de ta base de données.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
C'est ce qu'on l'on appelle une relation parent-enfant : c'est une relation sur la même entité, avec deux liens ayant chacun un sens, l'un allant de l'entité (ici "produit") vers la relation (ici "compose") et l'autre allant de la relation vers l'entité.
Tu saisie la différence ?
Si tu ne fais qu'un seul lien, comment sais-tu quel produit compose l'autre ? Et inversement ?
Ici pense bien qu'il s'agit uniquement d'un MCD, et non pas de la représentation même de ta base de données.
Dans ta base de données, tu n'auras au final qu'une seule table "compose", avec les deux champs identifiant.
Le fait qu'un identifiant se retrouve sur la première clef (master_id) signifiera qu'il est composé d'un autre produits, le fait qu'il se retrouve sur la seconde (slave_id) clef signifiera qu'il compose un autre produit.
Le MLD ne change pas cela dit, tu as raison sur ce point :) Et c'est bien le MLD qui se rapprochera donc le plus de la représentation de ta base de données.
~ N'oubliez pas la balise "Résolu" lorsque votre problème est... résolu :) ~
J'ai un petit soucis de compréhension avec phpMySQL (c'est la première fois que je l'utilise vraiment)
Surtout pour mettre les contraintes (foreign key)
J'ai créer les tables qu'il fallait :
Client (existait déjà)
Commande (que j'ai créé) : Com_id | int(6) | Not null | auto_increment
Prix_total_calculé | decimal (8,2)
Produit (existait déjà) : products_id | int(6) | not null | auto_increment
...
Inclut (que j'ai créé) : Quantité
Compose (que j'ai créé) : Master_id, Slave id => je n'ai pas pu les mettre tous les deux en auto_increment ! Faut-il que je m'en mette aucun des deux ou un des deux ? lequel ?
Obligatoire(true/false)
Nombre
Après quelques recherches j'ai vu que pour gérer les contraintes en mode graphique il fallait mettre le moteur en InnoDB pour pouvoir voir l'onglet gestion des relations.
Donc je vois bien comment ça marche, mais si j'ai bien compris il faudrait que je rajoute des champs vide ? dans mes tables (qui ont le même nom que la clé primaire ?) qui représenterai la clé étrangère ? et après je fais le lien grâce a gestion des relations !
Surtout pour mettre les contraintes (foreign key)
J'ai créer les tables qu'il fallait :
Client (existait déjà)
Commande (que j'ai créé) : Com_id | int(6) | Not null | auto_increment
Prix_total_calculé | decimal (8,2)
Produit (existait déjà) : products_id | int(6) | not null | auto_increment
...
Inclut (que j'ai créé) : Quantité
Compose (que j'ai créé) : Master_id, Slave id => je n'ai pas pu les mettre tous les deux en auto_increment ! Faut-il que je m'en mette aucun des deux ou un des deux ? lequel ?
Obligatoire(true/false)
Nombre
Après quelques recherches j'ai vu que pour gérer les contraintes en mode graphique il fallait mettre le moteur en InnoDB pour pouvoir voir l'onglet gestion des relations.
Donc je vois bien comment ça marche, mais si j'ai bien compris il faudrait que je rajoute des champs vide ? dans mes tables (qui ont le même nom que la clé primaire ?) qui représenterai la clé étrangère ? et après je fais le lien grâce a gestion des relations !
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
20 avril 2010 à 11:23
20 avril 2010 à 11:23
MySQL ne gère pas les liens via les clefs étrangères, du moins pas dans les anciennes versions, et j'ai appris avec les anciennes.
Pour le coup il suffit juste de faire le lien toi-même de la façon suivante:
- PRODUIT, a pour clef primaire 'id_produit'
- COMPOSE à pour clef primaire le couple 'master_id' et 'slave_id'. Ces deux identifiant sont exactement du même type que 'id_produit' (puisque ce seront des id de produit). Ces deux champs forment la clef primaire (composée) de la table 'COMPOSE'.
- INCLUT, aura les champs suivants:
+ id_produit
+ id_commande
+ quantité
'id_produit' ET 'id_commande' forment à elle deux la clef primaire (composée) de cette table. Ces deux identifiant sont exactement du même type que ceux de la table 'PRODUIT' et 'COMMANDE'.
- COMMANDE, comme tu l'as déjà dit
- CLIENT, comme tu l'as déjà dit
- PASSE, contiendra les deux clef primaires héritées des tables qu'elle lie, à savoir 'id_commande' et 'id_client' (exactement de même type que ceux des tables 'CLIENT' et 'COMMANDE'
Attention : Dans les tables représentant les associations de ton MCD, les clef primaires sont généralement un couple de champs "hérité" ou représentant des identifiants d'autres tables. Autant dans les tables elle-même ces identifiants uniques sont en mode auto-increment, autant dans les tables des relations, ces identifiants ne le sont en aucun cas !
Ces tables sont là pour représenter des liens, en aucun cas ils ne doivent être créé par le gestionnaire de la base de données.
En gros, lorsque tu créé une commande, tu créera une nouvelle entrée dans la table COMMANDE, dont le champ identifiant sera généré automatiquement par le gestionnaire de la BDD. Une fois ce champ récupéré (ainsi que celui d'un produit à lier à cette commande), tu pourra alors créer une nouvelle entrée dans la table "PASSE", en stipulant les identifiants ainsi récupérés.
Dans l'interface graphique d'EasyPHP, dans l'administration de la base de données, tu as possibilité de sélectionner plusieurs champs en tant que clef primaire de la table.
Ca te semble clair ?
Dans d'autres SGBD comme Orable, où les clefs étrangères sont gérées, c'est différents par contre, tu n'as pas à créer de tables intermédiaires comme c'est le cas ici de "PASSE" par exemple.
Pour le coup il suffit juste de faire le lien toi-même de la façon suivante:
- PRODUIT, a pour clef primaire 'id_produit'
- COMPOSE à pour clef primaire le couple 'master_id' et 'slave_id'. Ces deux identifiant sont exactement du même type que 'id_produit' (puisque ce seront des id de produit). Ces deux champs forment la clef primaire (composée) de la table 'COMPOSE'.
- INCLUT, aura les champs suivants:
+ id_produit
+ id_commande
+ quantité
'id_produit' ET 'id_commande' forment à elle deux la clef primaire (composée) de cette table. Ces deux identifiant sont exactement du même type que ceux de la table 'PRODUIT' et 'COMMANDE'.
- COMMANDE, comme tu l'as déjà dit
- CLIENT, comme tu l'as déjà dit
- PASSE, contiendra les deux clef primaires héritées des tables qu'elle lie, à savoir 'id_commande' et 'id_client' (exactement de même type que ceux des tables 'CLIENT' et 'COMMANDE'
Attention : Dans les tables représentant les associations de ton MCD, les clef primaires sont généralement un couple de champs "hérité" ou représentant des identifiants d'autres tables. Autant dans les tables elle-même ces identifiants uniques sont en mode auto-increment, autant dans les tables des relations, ces identifiants ne le sont en aucun cas !
Ces tables sont là pour représenter des liens, en aucun cas ils ne doivent être créé par le gestionnaire de la base de données.
En gros, lorsque tu créé une commande, tu créera une nouvelle entrée dans la table COMMANDE, dont le champ identifiant sera généré automatiquement par le gestionnaire de la BDD. Une fois ce champ récupéré (ainsi que celui d'un produit à lier à cette commande), tu pourra alors créer une nouvelle entrée dans la table "PASSE", en stipulant les identifiants ainsi récupérés.
Dans l'interface graphique d'EasyPHP, dans l'administration de la base de données, tu as possibilité de sélectionner plusieurs champs en tant que clef primaire de la table.
Ca te semble clair ?
Dans d'autres SGBD comme Orable, où les clefs étrangères sont gérées, c'est différents par contre, tu n'as pas à créer de tables intermédiaires comme c'est le cas ici de "PASSE" par exemple.
Donc j'utilise pas InnoDB et la gestion des relations pour faire les relations entre les tables ?
Mais je comprend pas alors comment les relations et les contraintes de DELETE ON CASCADE, ... vont se faire ?
Et comment on fait pour que par exemple dans la table COMPOSE Master_id et Slave_id soient des clefs héritées de products_id ?
Et dans PASSE je met le même nom alors que dans COMMANDE et CLIENT cad Com_id et CodeClient ?
J'ai fait de la base de donnée essentiellement sous Oracle (j'ai un peu de mal a visualiser comment les liens se font sous phpMySQL)
Mais je comprend pas alors comment les relations et les contraintes de DELETE ON CASCADE, ... vont se faire ?
Et comment on fait pour que par exemple dans la table COMPOSE Master_id et Slave_id soient des clefs héritées de products_id ?
Et dans PASSE je met le même nom alors que dans COMMANDE et CLIENT cad Com_id et CodeClient ?
J'ai fait de la base de donnée essentiellement sous Oracle (j'ai un peu de mal a visualiser comment les liens se font sous phpMySQL)
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
Modifié par kij_82 le 20/04/2010 à 12:13
Modifié par kij_82 le 20/04/2010 à 12:13
Effectivement, j'oubliais que tu devais le faire avec la gestion de clefs étrangères pour faire des DELETE ON CASCADE.
Je t'avoue que je suis pas très à l'aise avec ce genre de truc, habituellement je fais tout par moi-même dans des scripts, c'est plus compliqué à maintenir et à mettre en place, plus susceptible aussi d'inclure des erreurs, mais je n'ai appris que comme cela. Et les bases de données, je n'en fais malheureusement pas suffisamment pour justifier une auto-formation là dessus ^^'
Libre à toi d'utiliser ce qu'il a été dit plus haut (et fait niveau MCD/MLD) pour créer ta base de données en utiliser innoDB dans ce cas.
Je serai intéressé pour le coup d'oeil d'avoir ta solution une fois faite.
Je t'avoue que je suis pas très à l'aise avec ce genre de truc, habituellement je fais tout par moi-même dans des scripts, c'est plus compliqué à maintenir et à mettre en place, plus susceptible aussi d'inclure des erreurs, mais je n'ai appris que comme cela. Et les bases de données, je n'en fais malheureusement pas suffisamment pour justifier une auto-formation là dessus ^^'
Libre à toi d'utiliser ce qu'il a été dit plus haut (et fait niveau MCD/MLD) pour créer ta base de données en utiliser innoDB dans ce cas.
Je serai intéressé pour le coup d'oeil d'avoir ta solution une fois faite.
Bon j'ai mis en place la solution suivante :
J'ai changé le moteur en InnoDB pour les différents tables :
ClientBoutique (CodeClient, Nom, Adresse, CodePostal, Ville, Tel)
COMMANDE (Com_id, Prix_total_calculé, client_id)
avec client_id => type INDEX relié a ClientBoutique->CodeClient ON DELETE CASCADE
Produit (products_id, ... , Vendable(true/false))
INCLUT (Com_id, products_id, Quantité)
avec Com_id => type INDEX relié a COMMANDE->Com_id ON DELETE CASCADE
avec products_id => type INDEX relié a Produit->products_id ON DELETE CASCADE
COMPOSE(Master_id, Master_slave, Obligatoire(true/false), Nombre)
avec Master_id => type INDEX relié a Produit-> products_id ON DELETE CASCADE
avec Slave_id=>type INDEX relié a Produit-> products_id ON DELETE CASCADE
Je me suis pas occupé encore de la table OPTION
Je pense pas que ça soit idiot ce que j'ai fait mais je sais pas du tout si c'est correct !
y'a un moyen de vérifier ?
J'ai changé le moteur en InnoDB pour les différents tables :
ClientBoutique (CodeClient, Nom, Adresse, CodePostal, Ville, Tel)
COMMANDE (Com_id, Prix_total_calculé, client_id)
avec client_id => type INDEX relié a ClientBoutique->CodeClient ON DELETE CASCADE
Produit (products_id, ... , Vendable(true/false))
INCLUT (Com_id, products_id, Quantité)
avec Com_id => type INDEX relié a COMMANDE->Com_id ON DELETE CASCADE
avec products_id => type INDEX relié a Produit->products_id ON DELETE CASCADE
COMPOSE(Master_id, Master_slave, Obligatoire(true/false), Nombre)
avec Master_id => type INDEX relié a Produit-> products_id ON DELETE CASCADE
avec Slave_id=>type INDEX relié a Produit-> products_id ON DELETE CASCADE
Je me suis pas occupé encore de la table OPTION
Je pense pas que ça soit idiot ce que j'ai fait mais je sais pas du tout si c'est correct !
y'a un moyen de vérifier ?
Bon j'ai un petit soucis..
J'ai remplit les nouvelles tables que j'ai créées pour faire des tests.
Je voudrais que quand un produit master est défalquer tous les produits slaves qu'ils contient le soient aussi. Je pensais qu'avec les relations entre les tables avec DELETE ON CASCADE marcherait mais ça n'a pas l'air d'être le cas.
Cependant il faut que je gère aussi le fait que le client parmi le produit master a plusieurs options.
Par exemple pour un produit master : chambre de bébé il a le choit entre :
-une commode 1 tiroir, 2 portes OU une commode 3 tiroirs.
J'ai un peu de mal a visualiser comment faire pour mettre en place la solution adéquate, pour que le stock soit défalquer correctement lors de la validation de la commande d'un client.
Par exemple cette requête :
$query4 = "UPDATE products SET products_qt = products_qt -1 WHERE products_id = '530'";
//execute requête
mysql_query($query4);
Elle défalque bien d'une unité a chaque fois le stock ! Mais que le produit master !
Que dois-je faire pour que les autres produits contenu dans l'offre (commode, lit, ...) soient eux aussi défalquer correctement de façon automatique et direct !
Merci beaucoup.
J'ai remplit les nouvelles tables que j'ai créées pour faire des tests.
Je voudrais que quand un produit master est défalquer tous les produits slaves qu'ils contient le soient aussi. Je pensais qu'avec les relations entre les tables avec DELETE ON CASCADE marcherait mais ça n'a pas l'air d'être le cas.
Cependant il faut que je gère aussi le fait que le client parmi le produit master a plusieurs options.
Par exemple pour un produit master : chambre de bébé il a le choit entre :
-une commode 1 tiroir, 2 portes OU une commode 3 tiroirs.
J'ai un peu de mal a visualiser comment faire pour mettre en place la solution adéquate, pour que le stock soit défalquer correctement lors de la validation de la commande d'un client.
Par exemple cette requête :
$query4 = "UPDATE products SET products_qt = products_qt -1 WHERE products_id = '530'";
//execute requête
mysql_query($query4);
Elle défalque bien d'une unité a chaque fois le stock ! Mais que le produit master !
Que dois-je faire pour que les autres produits contenu dans l'offre (commode, lit, ...) soient eux aussi défalquer correctement de façon automatique et direct !
Merci beaucoup.
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
22 avril 2010 à 11:35
22 avril 2010 à 11:35
Salut,
DELETE ON CASCADE, comme l'instruction l'indique, permet de faire du DELETE en cascade en cas de suppression d'une valeur dans une table (ainsi que les valeurs auxquelles elle est la rattachée dans d'autres tables - éventuellement.
Du moins c'est comme ça que je le comprends, je ne l'ai jamais utilisé pour autant.
Pour faire de la mise à jour d'un champ d'un produit (ton stock dans ton cas) et le répercuter sur les sous produits, il faut simplement faire comme je te l'ai déjà indiqué dans un des post plus haut (par rapport au fait que ce qu'un client commande se trouve dans la relation 'PASSE' entre 'COMMANDE' et 'PRODUIT', et qu'à partir de ces informations, tu peux défalquer le nombre en stock de chacun des produits)
Je ne pense pas que tu puisse automatiser ce genre de traitement au même titre qu'un DELETE ON CASCADE, mais j'avoue ne pas m'y connaitre suffisamment en instruction SQL pour l'affirmer réellement.
DELETE ON CASCADE, comme l'instruction l'indique, permet de faire du DELETE en cascade en cas de suppression d'une valeur dans une table (ainsi que les valeurs auxquelles elle est la rattachée dans d'autres tables - éventuellement.
Du moins c'est comme ça que je le comprends, je ne l'ai jamais utilisé pour autant.
Pour faire de la mise à jour d'un champ d'un produit (ton stock dans ton cas) et le répercuter sur les sous produits, il faut simplement faire comme je te l'ai déjà indiqué dans un des post plus haut (par rapport au fait que ce qu'un client commande se trouve dans la relation 'PASSE' entre 'COMMANDE' et 'PRODUIT', et qu'à partir de ces informations, tu peux défalquer le nombre en stock de chacun des produits)
Je ne pense pas que tu puisse automatiser ce genre de traitement au même titre qu'un DELETE ON CASCADE, mais j'avoue ne pas m'y connaitre suffisamment en instruction SQL pour l'affirmer réellement.
