Bonjour à tous

J'ai commencé à créer un site qui vend des boxs, j'ai fait un croquis de la bdd mais je ne suis pas sur que mon approche soit la bonne. Que pensez vous de ma bdd ?

Explication:

Nous avons les utilisateurs qui peuvent ajouter des boxes (ensemble d'articles) ou des articles séparement dans un panier. C'est pour cela que j'ai créer un panier, qui est en relation manyToMany avec les box et les articles car plusieurs panier peuvent avoir le meme article (ou box) et le meme article (ou box) peut etre present dans plusieurs paniers. 

L'utilisateur peut aussi souscrire à un abonnement pour recevoir une box par mois pendant X mois. Les abonnements et les paniers sont les deux entity que l'on peut commander, c'est pour cela que j'ai créer deux champ id_panier et id_abonnement dans la table commande qui sera renseigné en fonction du type entité commandé.

Voici si dessous le shéma de la bdd.

Qu'en pensez vous ? Est ce que cela vous parrez correcte ?

Merci d'avance

Fred

-
Edité par methos0 17 juin 2021 à 14:55:54

Bonjour,

Remarque générale, je trouve plus pertinent de faire un MCD avant le MLD ... cela permet de mieux comprendre les cardinalités et leurs impacts sur le modèle logique et d'éviter les problèmes de cohérences dans les clés étrangères et autres joyeusetés relationnelles ... Tu peux par exemple utiliser Looping MCD, qui en plus te génère automatiquement le MLD et le SQL ...

Sinon, côté MLD :

Un abonnement ne concerne-t-il pas une box ? Dans tous les cas, j'aurais lier l'abonnement au panier  ... pour éviter cette colonne NULL dans la commande ...

C'est quoi la colonne stock dans la table des propriétés ?

-
Edité par Benzouye 17 juin 2021 à 16:31:27

Bonjour Benzouye!

Je n'ai jamais entendu parler de MCD Je vais me renseigné.

Le truc c'est que l'on ne peux pas prendre plusieurs abonnements en même temps, contrairement à une box ou un article. C'est pour cela que j'ai fait cela comme ça. (je m'apperçoit que item_id et type n'ont plus rien à faire dans la bdd). L'abonnement n'est pas lier à la box. Au début de chaque mois, on regarde qui est abonné et on envoi la box du mois.

Le nombre d'article avec la caractéristique en stock. Exemple un t-shirt qui a l'id 1, on l'a en jaune (caractéristique) et on en a 5 en stock. On l'a aussi en rouge et 4 en stock ... on peut remplir plusieurs caractéristique comme part exemple la taille. 

-
Edité par methos0 17 juin 2021 à 16:50:50

methos0 a écrit:

L'abonnement n'est pas lier à la box. Au début de chaque mois, on regarde qui est abonné et on envoi la box du mois.

OK.

methos0 a écrit:

on ne peux pas prendre plusieurs abonnements en même temps

OK, mais cela n'empêche pas de faire un lien avec le panier ... à toi de gérer côté applicatif un menu spécial abonnement, mais côté BDD ce sera stocké au même endroit ...

Au passage, je pense qu'une commande et un panier c'est un peu la même chose ... je virerai l'entité panier et ajouterai un status "panier", premier status d'une commande ...

methos0 a écrit:

Le nombre d'article avec la caractéristique en stock. Exemple un t-shirt qui a l'id 1, on l'a en jaune (caractéristique) et on en a 5 en stock. On l'a aussi en rouge et 4 en stock ...

Un t-shirt rouge XL cela fait un article et deux properties ... le stock tu le mets quelle property ?

Ce n'est pas terrible comme gestion de stock ... Je verrai plutôt une notion d'article et de déclinaison avec le stock porté par la déclinaison. Tu as l'article "T-shirt qui tue" et X déclinaisons :

• t-shirt qui tue rouge S
• t-shirt qui tue rouge M
• t-shirt qui tue rouge L
• t-shirt qui tue rouge XL
• t-shirt qui tue jaune S
• t-shirt qui tue jaune M
• etc.

Chaque article est lié à une ou plusieurs déclinaison et chaque déclinaison peut-être liée plusieurs propriétés. Le prix et le stock sont portés par la déclinaison (ni par l'article, ni par la propriété).

Merci pour ta réponse,

Benzouye a écrit:

Ce n'est pas terrible comme gestion de stock ... Je verrai plutôt une notion d'article et de déclinaison avec le stock porté par la déclinaison. Tu as l'article "T-shirt qui tue" et X déclinaisons :

J'avais pensé faire comme tu as dit mais comment tu fait pour récupérer tout les t-shirt S ou L ? Je voulais géré le stock coté applicatif en décrémentant simplement le stock de tout les attributs d'un item quand il est vendu. 

Benzouye a écrit:

OK, mais cela n'empêche pas de faire un lien avec le panier ... à toi de gérer côté applicatif un menu spécial abonnement, mais côté BDD ce sera stocké au même endroit ...

Au passage, je pense qu'une commande et un panier c'est un peu la même chose ... je virerai l'entité panier et ajouterai un status "panier", premier status d'une commande ...

Tu as raison en effet c'est fort similaire ... donc tu mettrais une autre relation manyToMany entre la commande et les abonnements ? 

Donc pour récupérer une commande j'ai minimum 4 jointures a faire (user, article, box et abonement)

-
Edité par methos0 17 juin 2021 à 20:15:45

Oki j'ai fait des modifications par rapport a tes remarques qui était justifié. Les articles maintenant on a un model : robe de la marque X, de prix X. C'est ce qui est commun à toutes les version de l'articles. A coté de cela tu as les caractèristiques propre à chaque article: les photos, le stock quelque soit le type d'article.... et enfin les paramêtres propre au type de l'article (ex: la taille pour les t-shirt, la couleur, la longueur de jambe pour les pantalons ...)

J'ai aussi rajouté une table média.

Qu'en penses tu ? 

Fred

-
Edité par methos0 19 juin 2021 à 17:32:40

Oui, je trouve cela bien mieux.

Remarque au passage, sur les tables de relation, normalement, on ne met pas de clé primaire auto incrémentée, mais une clé primaire composée qui reprend les deux id liés ... Après je sais que certains ORM n'aime pas cela ... mais en toute rigueur c'est ainsi que cela devrait être formalisé ...