Discussion :

[Freddo31]

Salut tout le monde.
je souhaites réalisé, sur demande d'un ami à moi, une sorte de site servant à prendre des commandes de divers modules.
je m'explique.
C'est pour un jeu en ligne qui s'appelle EmpireUnivers II,
on peu acheter des modules à d'autres joueurs
chaque module a un prix et une description
chaque module appartient à une catégorie (il y a 4 catégories différentes)
un client doit s'être identifié de par son login et un mot de passe pour accéder au catalogue.
un client peut commander un ou plusieurs modules de une ou plusieurs catégories.

une fois validé, la commande est récapitulé au client pour confirmation.


voila, donc la question de l'analyse me tourmente un peu...je sais qu'un mauvaise base de donnée peut mettre en péril un projet...donc je m'en réfère à vous.

ce que je pense faire :

- Une table client avec les champs login, mdp, mdp_bis, email, prenom, nom_empire, nb_commande, total_des_commandes
- Une table modules avec les champs nom_module, categorie_module, description, prix
- Une table commande avec les champs log_client, nom_module_commande, qte, prix_total
--> log_client référence login de la table client
--> nom_module_commande référence nom_module de la table module


voila, donc je sais pas si cette analyse est la meilleure solution...et surtout, je me pose la question suivante...si un client commande 2 modules différents...dans ma table commande, j'aurais plusieurs lignes pour une même commande, non?


donc que me conseillez vous?
je précise que je travaille avec WampServer pour la conception de la BDD, et le dev PhP se fera sous Dreamweaver Cs4

merci.

[Metafire18]

Pourquoi mettre un attribut mdp et un attribut mdp_bis dans la table client?
Sinon je pense qu'une commande devrait être symboliser par une relation entre un client et plusieurs modules.

Client--0,n-----Commander-----0,n--Module

[Freddo31]

le mdp et mdp_bis c'est juste pour un contrôle au niveau de l'inscription, pour une vérification du mot de passe.

donc suivant ton schéma, j'ai besoins que de 2 tables?
de plus, je ne sais pas comment créer des clès étrangère avec PhPmyAdmin...
mais pour une commande, il peut y avoir plusieurs modules commander...donc à quoi ressemblerai la requête d'insertion...j'ai du mal à voir comment on peut stocker tout les modules dans une seule ligne de la table...

[f-leb]

bonsoir,

concernant la partie Client-Commande/Commander-Module, ce ne sont pas les discussions qui manquent sur ce forum. Par exemple, [MCD] gestion des ventes (Tiens! Metafire18 était déjà dans le coup)

le mdp et mdp_bis c'est juste pour un contrôle au niveau de l'inscription, pour une vérification du mot de passe.

oui mais lorsque l'inscription est validée, ta base va stocker deux fois le même mot de passe, non ?

[Freddo31]

oui, stocké 2 fois dans la BD, en cryptée.
ça sert au client au niveau de l'inscription pour être sur qu'il a rentré 2 fois les bon mdp

pour le lien que tu m'as donné, c'est gentil, merci, mais j'ai du mal à comprendre tout ce qui a été dit...:s

si j'ai bien compris...dans mon cas, il ne suffit d'avoir que 2 table, client et module, et lors du passages au MLD, la table commande sera crée vis à vis des cardinalité avec comme attribut le login du client + le nom du module, et ces 2 attributs formeront la clès primaire.
mais il faut bien un identifiant à cette nouvelle table? donc au départ, il ne faut pas que ça soit une relation si?

[Metafire18]

oui, stocké 2 fois dans la BD, en cryptée.
ça sert au client au niveau de l'inscription pour être sur qu'il a rentré 2 fois les bon mdp

Cette vérification doit être effectuée au niveau programmation au moment où l'utilisateur saisit son mot de passe pour la première fois. Si il saisit le mot de passe de façon identique dans le champ du mot de passe et dans le champ de validation du mot de passe, alors tu insère le mot de passe dans ta table

pour le lien que tu m'as donné, c'est gentil, merci, mais j'ai du mal à comprendre tout ce qui a été dit...:s

si j'ai bien compris...dans mon cas, il ne suffit d'avoir que 2 table, client et module, et lors du passages au MLD, la table commande sera crée vis à vis des cardinalité avec comme attribut le login du client + le nom du module, et ces 2 attributs formeront la clès primaire.
mais il faut bien un identifiant à cette nouvelle table? donc au départ, il ne faut pas que ça soit une relation si?

En fait, si on adapte le modèle de Cinéphil à ton cas, cela donne le modèle suivant:
Client -0,n----Passer----1,1- Commande -1,n----Contenir----0,n- Module

[Freddo31]

Voila une image de mon MCD,
mais je pense qu'il n'est pas encore bon...j'ai des soucis avec mes attributs...je sais pas si le nombre de module commandé doit être dans la table module ou dans la table commander?
je ne vois pas ce que je peux/dois mettre dans la table commande...

[Metafire18]

Voila une image de mon MCD,
mais je pense qu'il n'est pas encore bon...j'ai des soucis avec mes attributs...je sais pas si le nombre de module commandé doit être dans la table module ou dans la table commander?

Ni dans l'une ni dans l'autre Le nombre de modules commandés est porté implicitement par la relation Contenir. Par exemple, on peut obtenir les enregistrements suivants avec ce MCD :

id_commande.....id_module
1................................1
1................................2
2................................5
3................................4
3................................7
3................................2

On voit que la commande n°1 concerne deux modules, la n°2 concerne 1 module et la n°3 concerne trois modules. Inutile donc de faire figurer cette information dans une table puisqu'elle est déjà portée par la structure de ton MCD

[Freddo31]

ah oui, je vois!

ok, donc la mon MCD ressemble à ça



et si je veux conserver la date de chaque commande, je dois créer une entité date reliée à passer?

[CinePhil]

La date de la commande est un attribut immuable (en principe) de l'entité commande.

[Freddo31]

Ok, alors il suffit de rajouter l'attribut date à l'entité commande!!!


après, si un jour, je veux sortir des stats sur quel client a passer quelle commande, sur le nombre d'argent qu'il a dépensé (total de ses commandes)...etc...il suffirait de faire des calculs avec les requêtes...donc pas la peine de les stocker dans la base de données...

si je comprends bien?

[CinePhil]

Ok, alors il suffit de rajouter l'attribut date à l'entité commande!!!

OUI

après, si un jour, je veux sortir des stats sur quel client a passer quelle commande, sur le nombre d'argent qu'il a dépensé (total de ses commandes)...etc...il suffirait de faire des calculs avec les requêtes...donc pas la peine de les stocker dans la base de données...

si je comprends bien?

Il y a un petit piège concernant les prix.
Ton MCD actuel fait que si le prix du module change, le résultat des calculs que tu envisages changeront aussi !
Il faut donc stocker dans l'association Contenir toutes les données susceptibles de changer dans le temps, si tu veux garder la trace du passé.
Le prix unitaire auquel a été vendu le module bien sûr mais aussi peut-être le taux de TVA car il peut changer, voire le prix total si une remise peut être accordée sur une ligne de commande.

Ce n'est peut-être pas le cas ici mais attention aussi au colisage !
Tu vends aujourd'hui 5 machins vendus par 10, donc 50 exemplaires. Dans le futur, ton colisage passe de 10 à 50. Si l'unité n'a pas été stockée avec la commande, tes stats seront fausses.

[Freddo31]

je vois ce que tu veux dire!!
cependant, dans mon cas, le prix peut changer certes, mais pas d'histoire de TVA.

donc dans ce cas, il suffit de mettre dans contenir un attribut prix_commande, et de laisser le prix du module dans la table module.
je pense que la c'est bon

[CinePhil]

je vois ce que tu veux dire!!
cependant, dans mon cas, le prix peut changer certes, mais pas d'histoire de TVA.

En es-tu bien sûr ?
La TVA sur la restauration vient de baisser de catégorie (et donc de taux).
Imagine que demain, pour relancer l'économie, le gouvernement décide de baisser la TVA normale de 19,6% à 15% ? (on peut rêver quand même ! )

Ou alors tu met un code de TVA et tu historises les taux de TVA.

Le principe général est qu'il faut se prémunir de ce qui peut changer.

[Freddo31]

oui, je suis sur étant donnée que ma base de donnée stocke des modules pour une jeu ONLine