Je viens solliciter votre aide car je galère sur la conception d'un MCD et puis comme je suis encore étudiant je ne maîtrise pas encore à fond.
Bon voilà le truc:
Je veux créer une base de donnée qui gère les prestations que propose une entreprise (une esthéticienne pour être précis).
Il y'a donc deux et exclusivement deux prestation:
- la vente de produits cosmétique (crème, etc...)
- la vente de services (épilation, soins, etc...)
Il y'a une catégorie et une sous-catégorie pour chaque prestation.
Je veux aussi pouvoir avoir un historique des services et des produits commandés (d'où les tables Achat et Commande ainsi que les relation ligne_ pour enregistrer la quantité acheté "qte_achetee" de produit en propriété portée)
Aussi à la base je voulais enregistrer les clients avec leurs données mais avec la loi RGPD...
Mon premier prototype donnait ça (avec la table client):
Dite moi ce que vous en pensez ça m’intéresse
Mais du coup j'ai décidé de supprimer cette table client et d'instaurer un lien d'héritage:
Encore une fois dite moi ce que vous en pensez
Mais voilà déjà je ne sais pas si ce second MCD est correct et surtout comment je fais pour avoir l'historique des services et des produits commandés ?
C'est pour cela que je viens vous contacter car je suis au bout de ma vie actuellement (non je plaisante)
Personnellement, je te propose d'envisager cela sous un autre angle et de partir sur ce qui devrait être central : la facture (ce qui revient à raisonner en terme "d'acte" commercial).
Ne serait-ce déjà que pour une question de vocabulaire et parce que c'est l'élément juridique de base. En effet, on ne parle pas en général de "prestation" pour une vente d'objets, c'est en principe réservé à un service.
Ensuite, le "service" devrait être lié à une "catégorie" et la "catégorie" à une "sous-catégorie" et non l'inverse.
Et avant d'aller plus loin, il faudrait préciser si les catégories de "produits" ou de "service" peuvent se recouper ou pas (par exemple si tu as une catégorie "soin du visage" tu pourrais retrouver à la fois des services et des produits dedans).
le "service" devrait être lié à une "catégorie" et la "catégorie" à une "sous-catégorie" et non l'inverse
Je ne suis pas d'accord avec ça, pour moi c'est bien la sous-catégorie qui est portée par le service ...
philodick a écrit:
de partir sur ce qui devrait être central : la facture
Encore pas d'accord, ce qui est central ici c'est le produit (ou article plutôt, que ce soit de la prestation ou du négoce). Il faut de toute façon réfléchir de manière globale.
Je te propose déjà de simplifier les choses sans te prendre la tête à distinguer service de produit vu que la seule chose qui les distingue c'est "durée" et "marque" :
Un simple attribut "type" dans une entité "article" pour distinguer produit de service (valant par exemple "P" ou "S")
Une entité "marque" liée à cette entité "article" et qui sera vide si l'article est un service
Pas d'attribut stock dans l'entité "article", le stock est un calcul, pas un attribut
Le MCD pourrait être celui-ci :
L'entité article est centrale. Achats et ventes s'appuient sur une relation n,n avec les articles.
L'entité client devra en effet être gérée correctement pour répondre au RGPD, mais si l'accord de vente explicite clairement la gestion qui est faite des données personnelles (quoi, comment, quand), alors l'acceptation formalisée de la vente (bon de commande signé par exemple) est suffisante pour être conforme au RGPD.
Merci beaucoup pour vos retours et pour le travail que vous avez fourni c'est ouf et désolé de ne pas avoir répondu plus tôt j'avais des examens toutes la journée.
Bon si je comprend bien dans ma table article j'aurais les produits ET les services qui y seront enregistrer ? Et du coup si je veux récupérer seulement les produits je ferais une requête SQL du style :
SELECT * FROM Article WHERE Article.type = 'P'
A vrais dire j'y avais pensé le truc de l'attribut dans une grosse entité pour distinguer les produits des services mais je pensais que c'était pas super propre comme conception (sans vouloir contrarier qui que ce soit hein ). Mais cela me rassure au final.
On retrouve bien les relations commande_article, achat_article ainsi que les tables Achat et Commande pour avoir un historique ça c'est cool !
Si je comprend bien commande_article et commande servent à l'historisation quand un client commande un service ou un produit. Et achat_article et achat servent à l'historisation des achat que l'esthéticienne effectue quand elle veut remplir ses stocks.
Concernant notre histoire des catégorie et des sous-catégorie, je m'étais dis : "un service (par exemple) peut appartenir à plusieurs sous-catégorie et une catégorie peut avoir plusieurs sous-catégorie mais on ne peut pas avoir un service directement dans une catégorie"
Le model de Benzouye prend en compte les fournisseur et la marque. Bon je ne suis pas encore à un stade aussi avancé, je ne gérait que la marque mais le fournisseur peut être remplie par l'utilisateur je pense que c'est pas trop compliqué à mettre en place.
Par contre pour la gestion des stock, là j'ai pas compris . Faut bien enregistrer quelque part les stocks pour qu'on puisse soustraire justement ? A moins que l'on ne s'en préoccupe pas et qu'elle ne vende les produit qui si il lui en reste. Dans ce cas mon application ne pourras pas lui renseigner son stock de produit en temps réel.... (ça m'embête mais bon )
L'esthéticienne vend les produits qu'elle utilise, c'est-à-dire que son stock de produit personnel pour travailler est le même que celui des produits qu'elle vend.
Mais la ça me pose un problème, les services ne peuvent pas avoir de stock car c'est quelque chose d'immatériel. A moins que par défaut je dis que si le type d'un article est "S", je l'initialise à 0, et dans ce cas je ne déduis la quantité au stock que quand c'est un produit qui est commandé et pas quand il s'agit d'un service.
Et puis pour la durée... ben on peut en faire une table séparer relié à article et dire que un article peut avoir 0,1 durée en fonction de si c'est un produit ou un service. Dites moi
Donc ça veut dire qu'un service appartient obligatoirement à une sous-categorie ? Cela me paraît un peu bizarre, mais si tu tiens à cette contrainte pourquoi pas. Cela implique quand-même que chaque catégorie aura une sous-catégorie, c'est pas super souple.
Chaque petite image (qui sont des liens) sur la page d'accueil sont pour moi des catégories. En suite (quand on clique sur un lien) on a plusieurs tableauwx avec des titres, c'est ça que j'appelle des sous catégorie (je sens que je vais me faire taper sur les doigts).
C'est vrais que ça apporte une forte contrainte...
si je veux récupérer seulement les produits je ferais une requête SQL du style :
SELECT * FROM Article WHERE Article.type = 'P'
C'est bien ça, la différence entre produit et service étant tellement minime en terme d'attribut que je trouve cela inutile de les dissocier (par héritage).
Qui_a_ToZ a écrit:
je m'étais dis : "un service (par exemple) peut appartenir à plusieurs sous-catégorie et une catégorie peut avoir plusieurs sous-catégorie mais on ne peut pas avoir un service directement dans une catégorie"
Cela change les cardinalités de la relation entre article et sous-catégorie. Si tu veux vraiment qu'un article puisse appartenir à plusieurs sous-catégories, il faut donc une relation n,n (et donc une table de relation au final).
Qui_a_ToZ a écrit:
Faut bien enregistrer quelque part les stocks pour qu'on puisse soustraire justement ?
Le stock est un calcul : la somme des achats moins la somme des ventes ... que tu peux donc calculer au besoin à partir des deux tables de relation achat et vente. Pas besoin de stocker le résultat du calcul, ce qu'il faudrait faire avec un TRIGGER qui au final ralentirait plus l'application qu'autre chose ... Si le volume de données (entrées et sorties) devait exploser (plusieurs dizaines de milliers), alors tu pourrait toujours revoir ce point là ...
Qui_a_ToZ a écrit:
les services ne peuvent pas avoir de stock car c'est quelque chose d'immatériel
On est d'accord, du coup lorsqu'un article est de type "S", alors tu ne calcules pas son stock ...
Qui_a_ToZ a écrit:
L'esthéticienne vend les produits qu'elle utilise, c'est-à-dire que son stock de produit personnel pour travailler est le même que celui des produits qu'elle vend.
Dans ce cas, il faudra mettre en place un système de sortie de stock pour ce que consomme l'esthéticienne. Avec mon modèle cela se ferait en créant des commandes pour un client "bidon" (nommé "Salon esthéticienne" par exemple) qui contiendrait les articles que l'esthéticienne a consommé pour elle et non vendu à un client.
Qui_a_ToZ a écrit:
Et puis pour la durée...
La durée serait pour moi dans l'attribut quantité de la relation commande_article. Exemple : l'article est "massage californien" et dans la commande tu mets une quantité de 0.25 (pour 1/4h) ou 0.5 pour 1/2h), etc. (ou tu peux choisir de saisir en minutes ou en secondes) ... Cela pourrait d'ailleurs être sympa de créer une entité "unité" lié à l'entité "article" qui indique dans quelle unité on comptabilise cet article (unité, heure, minute, seconde, litre, etc.).
philodick a écrit:
Cela implique quand-même que chaque catégorie aura une sous-catégorie, c'est pas super souple.
Il suffit de systématiquement créer une sous-catégorie lorsque l'on crée une catégorie, quitte à lui donner le même nom ... pas super, mais tellement plus simple à gérer ...
Au pire tu peux aussi créer des articles sans renseigner la sous-catégorie ...
Je pense surtout que tu te prend beaucoup la tête sur des détails secondaires (optimisation du calcul de stock, séparation produit/service...) sans prendre en compte des points qui pourraient devenir bloquant par la suite.
Première chose une gestion de catégorie/sous catégorie peut se faire en une seule table liée à elle même
Du coup chaque catégorie peut référencer une catégorie parente. Tu peux donc avoir au plus haut niveau les catégorie produit et service (id 1 et 2 par exemple et qui n'auront pas d'idParent)
Puis en dessous les cosmétiques qui auront pour idParent 1 (produit) etc... (niveau infini)
A partir de la une table de "Produit" (à renommer peut être) qui englobera tout ce qui peut être vendu et qui référence une catégorie (parente ou enfant ou enfant de enfant de... peu importe on arrivera à partir de n'importe quelle sous catégorie à remonter jusqu'à la catégorie principale facilement)
Je n'ai volontairement pas indiqué de prix dans le produit, car c'est un soucis sur lequel je reviendrais après la facture.
La facture c'est un achat réalisé par un client, tu ne souhaites peut être pas conserver les informations client pour t'éviter les contraintes RGPD, je fait donc sans. Une facture c'est tout simplement un ensemble de produit acheté à une date.
J'ai ajouté une table intermédiaire pour lier une facture à un ensemble de produit, et une quantité pour pouvoir acheter plusieurs fois le même produit.
Reste à savoir le prix qui a été payé, et c'est là qu'il y a un détail à prendre en compte.
Imaginons qu'aujourd'hui l'esthéticienne vend un produit P au prix de x€
Elle le vend à un client la facture est faite, tout va bien.
Si je met le prix x dans la table produit, je serais capable de calculer le montant de ma facture.
Mais demain, le fourniseur décide d'augmenter le prix de son produit, l'esthéticienne l'achète donc plus cher, et décide aussi de le revendre plus cher pour conserver sa marge. elle passe le prix du produit à y€
Si après cette modification je récupère ma facture de la veille, il apparaîtra que mon produit à été vendu à y€, hors ce n'est pas le cas, il a été vendu à x€. L'historique est incorrect, et je lui souhaite bon courage pour sa comptabilité...
Il faut prendre en compte que les prix peuvent changer, pour autant les facture doivent apparaître avec le prix vendu à la date de facture. Je procéderai donc en ajoutant une table de prix en fonction de la date.
la date de fin pouvant être null, ainsi pour récupérer le prix du produit "maintenant" il suffit de rechercher le prix associé à l'id du produit, avec une date de début inférieur à la date du jour, et une date de fin null
Enfin pour la gestion du stock, comme l'a expliqué mon prédécesseur, c'est un calcul d'entrée sortie et non pas un nombre fixe. On a déjà les sorties avec la facturation, il suffit alors d'avoir une table supplémentaire pour les entrées (approvisionnement)
J'ai ajouté un prix dans l'approvisionnement, qui pourra aussi, avec un peu de calcul, de vérifier la marge instantanée ou sur une période pour chaque produit.
Le stock dispo à un instant T, reviens simplement à faire la somme des approvisionnements (A) et d'en retirer la somme des produits facturé (F)
S = A - F
Et peut être travailler un peu le sql (et des procédures stockées?) pour obtenir des données correspondant à chaque besoin.
Pour info, en fin de réalisation, on se rend bien compte que l'élément central du modèle est le produit.
Edit :
Si tu souhaites qu'un produit apparaisse dans plusieurs catégorie, il suffit de changer la relation produit catégorie en n..n avec une table de liaison (comme facture avec produit par exemple)
L'approvisionnement est facultatif, il n'est pas obligatoire d'avoir systématiquement des lignes pour chaque produit dans le modèle que je te propose, donc ce ne sera le cas que pour les produits et non pas pour les services.
Attention de gérer le calcul pour ne pas qu'il plante s'il s'agit d'un service du coup.
@Mostuf, sans méchanceté aucune, tu répètes ce qui a déjà été répondu plus haut ...
Après, personnellement, je déconseille fortement l'arborescence récursive avec la structure réflexive que tu proposes. Tout d'abord parce qu'elle est récursive et que cela implique une gestion souvent tordue avec MySQL plus que ce que ça n'apporte de vrais avantages, ensuite parce qu'ici le contexte ne l'indique pas puisque la profondeur de l'arborescence est fixe (2 niveaux).
Ensuite sur l'évolution des prix, mon modèle stocke le prix actuel au niveau de l'article, et le prix au moment de la commande dans la relation article/commande. Sans se prendre la tête avec une nouvelle entité prix et la gestion des intervalles de dates, cela permet de conserver l'historique de prix de vente ... et je pense que l'on est pas ici dans un cas d'application à grande échelle et à grosse volumétrie ...
Enfin, le RGPD, n'est pas d'une très grande complexité sur ce genre de cas simple où le client est physique et qu'il accepte de fait les conditions d'utilisations de ses données, du moment que c'est écrit et que l'accès en "suppression / mise à jour" est possible.
Je sais que j'ai repris certains éléments qui avaient déjà été dit, mais d'autres me posent soucis, pour commencer une colonne type avec un char 'S' ou 'P' me parait très peu recommandable, c'est une mauvaise pratique qui entraine une redondance des données (même si ce n'est qu'un seul caractère).
Sur de petits volumes, l'impact sera insignifiant, mais c'est une mauvaise pratique qui peut engendrer une surconsommation de l'espace de stockage, et un manque de performance sur le requêtage. L'utilisation récursive permet de gérer justement à la fois des différents types de produits (avec des catégories parentes Produit et Service, comme je le recommande) mais aussi les catégories et sous catégories (et éventuellement plus si un jour l'envie lui prend d'en mettre plus)
Idem pour le prix, le stocker au niveau de la commande va entrainer une duplication de la données superflue.
Je suis d'accord pour RGPD, c'est simplement qu'en terme de bdd ça ne change pas grand chose (une table client relié à facture) et c'est un choix à faire par le développeur.
Bref, je suis d'accord avec toi, certains choix que tu as fait sont peut être "suffisant", car moins complexe et répondant au problème, mais j'oriente mes réponses pédagogiquement, afin que l'auteur du post puisse prendre du recul sur ce qu'il fait (et ce qu'il fera à l'avenir, peut être avec de plus grosse volumétries). Chacun son avis
Je te rejoins sur l'intérêt de l'entité prix, mais comme elle implique une gestion plus délicate et rigoureuse de la part de l'utilisateur pour tenir à jour les données, je ne pense pas qu'elle soit pertinente dans ce contexte, on ne parle pas d'une multinationale qui a une personne personne dédiée pour gérer le catalogue des prix
Par contre je maintiens que l'arborescence récursive n'est pas une bonne idée, même si théoriquement séduisante, car elle permet justement l'extension des niveaux d'arborescence et par la suite des usines à gaz en terme de code pour afficher les IHM de gestion nécessaires. De plus, cela engendre souvent un lien fort entre la base et l'application, avec la présence de d'identifiant en dur dans le code.
Par ailleurs, l'argument volumétrie ne tient pas non plus selon moi. Pour stocker un article, c'est le libellé qui représentera la majeure partie de l'espace occupé physiquement (101 octets pour un VARCHAR(100)). Le CHAR(1) de la colonne type, occupant un seul octet, ne va pas fondamentalement changer la donne de l'espace occupé par un article (1%) ...
Au passage, je suppose fortement qu'un produit et qu'un service peuvent se retrouver dans la même sous-catégorie ... Que fait-on on dans ce cas avec ton modèle ? On multiplie les catégories pour qu'elles soient disponible pour les services et les produits ? pas glop ...
Enfin, je suis d'accord sur l'aspect "pédagogique" de la "prise de recul" en voyant un modèle plus complet, rigoureux, pro.
Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.
Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre. En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.
Au lieu de déterrer un sujet il est préférable :
soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
soit de créer un nouveau sujet décrivant votre propre contexte
ne pas répondre à un déterrage et le signaler à la modération
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.