Bonjour à tous,

Alors voila je suis en stage pour une association de broderie qui souhaite monter un site de vente en ligne afin de pouvoir s'acheter plus de materiel car leur subventions ne suffise pas. J'ai réfléchie à une base de données mais n'étant pas sur qu'elle soit valide j'aimerais avoir le retour de quelques personnes et si elle n'est pas valide obtenir quelques conseil. Je vous remercie et bonne journée.

PS: Je sais déjà que j'ai oublié de mettre le pass pour les clients ms c'est modifié



[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

Salut,
quelques observations "à l'arrache" :

• la relation client/panier est à l'envers : de la façon dont tu l'as faite, un client ne pourrait avoir qu'un seul panier et un panier pourrait appartenir à plusieurs clients;
• dans ton entité panier, tu as une propriété "prix_total" : c'est un champ calculé, je ne suis pas certain que ce soit très approprié, en principe on évite systématiquement les valeurs calculées dans une base;
• Comment fais-tu le lien entre le panier et les produits ? Comment sauras-tu quel(s) produit(s) contient ton panier ? En fait, tu fais une liaison entre produit et client au lieu d'une liaison entre panier et produit, or un produit peut se retrouver dans 0:n panier(s) et un panier peut contenir 1:n produit(s) : tu devrais donc avoir une relation n:m entre panier et produits, ce qui va créer une table relationnelle dans laquelle tu pourras ajouter une colonne "quantité" par exemple.

Voilà, ce sont juste des notes rapides, je n'ai pas plongé en détails sur le reste, mais ces points là me selblent les plus gros à reconsidérer

la validité d'une base de donné est un concept trés flou à vrai dire puisque le moteur va inévitablement refuser toute syntaxe sql qui ne sera pas de sa compréhension.

En revanche la pertinence d'une base de donnée c'est quelque chose de plus observable ce que je te conseille déjà c'est de créer des tables de manière à ce qu'il n'y en ai pas trop sans pour autant avoir un modèle monolithique, de placer des index sur chaque table, certaines méthodes disent de l'appeller id_nom_de_la_table maintenant je sais que moi je préfère utiliser id comme champ récurant de chacune de mes tables (ça peut être interpréter comme une mauvaise habitude et peut compliquer le debugging éventuel mais ça raccourci le code )

Donc, fais tes tables ensuite exporte les et vient nous poster le schéma qu'on puisse en parler.

Attention : modéliser une base de données, c'est d'abord conceptualiser l'organisation des données. On ne parlera donc pas de créer des tables d'entrée de jeu. Il est de très loin préférable de commencer par penser en terme d'entités/propriétés. Après seulement on convertira le résultat en tables et en colonnes. C'est le modèle conceptuel de données, puis le modèle physique de données et après seulement on parlera de tables : c'est la méthode MERISE. un petit tour sur Google t'en dira sans doute davantage encore, il y a même des tutos en ligne sur le sujet.

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

Oki,
je vous remercie pour vos réponses je prend en compte ce que vous m'avez dit et reviens donc après avec une base "valide" je l'espère. Bonne journée

EDIT :

Alors voila apès avoir suivit les conseils de 'Invité' et Cyrano j'ai ressorti mes cours de Merise et planché un peut dessus. Voila comment j'ai procédé :
1) Ecriture du SI.
2) Identification des entités.
3) Listage des propriétés des entités.
4) Mise en place des identifiants.
5) Mise en place des relations entre les entités.
6) Identification des cardinalités.

J'en suis donc arrivé à ca :



Voyez vous encore des erreures ?

Ben voilà, c'est à mon avis beaucoup mieux.

Il reste quand même le problème des champs calculés dans ton entité "panier" : ce sont des valeurs que tu peux obtenir ... par calcul sur des jointures entre le produit et une valeur qui serait à rajouter dans ta relation entre "panier" et "produit" à savoir "quantite". Donc pour moi ces deux propriétés n'ont pas lieu d'être tout simplement. Par contre pour des besoin d'archivage, rien n'interdit de stoker dans une entité indépendante ces informations quand elles sont complètement terminées, commande payée et livrée de façon à pouvoir éditer un historique des commandes pour des besoins statistiques par exemple.

Un dernier point resterait peut-être à considérer : l'adresse de livraison, sera-t-elle la même que celle de l'acheteur ? C'est un classique de la vente en ligne, on peut acheter pour faire livrer à un parent, un ami ou qui tu voudras. Dans ce cas, il faudrait séparer le client et l'adresse en deux entités et ajouter une propriété pour l'adresse qui permet de définir si c'est une adresse de livraison ou l'adresse de facturation par exemple. Et dans ce cas tu auras un client qui peut avoir 1:n adresse(s).

Enfin, il va aussi rester un problème : la gestion des commandes. Suppose qu'un client passe commande sur le site et paye en ligne : actuellement, cette partie n'est pas du tout prise en compte. Donc tu pourrais ajouter une propriété dans "panier" qui va permettre de définir une commande comme "payée" (donc confirmée), expédiée (à gérer en backoffice pour le suivi de commande), rejetée (paiement refusé par la banque par exemple ou encore transaction non terminée par le client).

Tu es à mon avis sur une très bonne voie, continue dans ce sens

Merci pour tes nombreux conseils. Je viens de discuter avec ma chef (qui n'a pas beaucoup de connaissance informatique) et nous avons décidé :

Je retire les prix et le poids du panier car ils se calculent automatiquement lors de l'affichage.

Ensuite après validation du panier on arrive sur une nouvelle page qui propose le paiements soit par chèque soit par paypal ( Pas de paiement bancaire sécurisé leur banque étant la poste ca coute trop chère ). Si le client choisit par chèque on arrive donc sur une page proposant l'enregistrement du client de son adresse et le cas échéant de l'adresse de livraison le client doit confirmé. Un récapitulatif de la commande s'affiche si il accepte je crée un enregistrement dans la table Commandes ( que je vais créer ). Sachant que la facture sera toujours envoyé à l'adresse du client.
Si le client choisit le paiement par paypal c'est paypal qui gère tout et envoie un mail récapitulatif.

Que pensez vous de cette technique ?

Ma tables Commandes serait composé : d'un ID, de l'id du client (pour pouvoir envoyer la facture) et de l'adresse de destination du colis et du montant de la facture pour que les comtes soit plus facile à faire.

Et comment va tu sauvegarder en base de données les commandes des personnes ayant payés par paypal ?
J'ai l'impression, en lisant ta description, que tu n'enregistres une commande que si paiement par chèque

Dans la partie administration je peut rentrer une commande dans la table Commandes car je n'ai pas accès à ce qu'il se passe chez paypal je reçois juste un mail de confirmation de leur part, de plus l'association tien tous ses comptes dans des cahiers à la main qui est présenté tous les mois à tous les membres (ménagères en général +40 ans)
De plus je ne vois pas comment faire... mais tous les paiements reçu chez paypal sont sauvegardé dans le compte paypal peut être pourrais-je voir de ce côté. Histoire a suivre.
Merci de la remarque

EDIT : Je viens de m'apercevoir d'un problème : avec les liaisons faites je n'ai pas le choix lorsque je rentre un produit dans la table de lui mettre un motif et une couleur or ce choix appartient au client puisque c'est une association de broderie personnalisé. Je m'explique. Lorsqu'un client vient sur le site il choisit son produit ( serviettes, torchons, peignoir ) , la couleur ( vert, orange, bleue ) et le motif ( ourson, ballon, fleur )qu'il y a dessus et c'est seulement par la suite que la produit vas être "assemblé" cela veut-il dire que je ne doit pas faire d'association entre les tables Couleurs, Motifs et Produits et juste créer des tables ?

Doit-je quand même gardé les associations entre Clients, Paniers, Frais de port, et Produits ? (A mon avi oui).
Là j'ai franchement besoin d'un bon éclairsissement.