Schémas basique database clients-commandes.

Bonjour à tous...

Voilà, je me remets au SQL, bien que je n'y aie plus touché depuis des années et des années... Je crée pour l'instant de petites tables simples dans le but de tout remettre dans ma petite caboche ^^ Je vous expose mon problème :

J'ai créé une database qui a pour but de gérer les commandes d'un magasin ( fictif ), dans cette db, j'ai créé :

1 table Clients ( ID PK autoinc, nom, prenom, adresse ...)
1 table produits ( ID PK autoinc, denomination, prix, reduction )
1 table de jointure commandes (ID PK autoinc, ID_commande, ID_client FK, ID_produit FK)
1 Vue pour voir qui passe commande, à partir de la table de jointure.

Mon problème est que je ne vois pas trop comment je peux associer plusieurs produits à une commande, sans pour autant dédoubler l'information d'ID_commande dans ma table du meme nom. Sachant qu'un enum et un set sont limités à 64 enregistrements si mes souvenirs sont bons.

Auriez vous une solution pour rendre ceci "Pretty" ?
Merci d'avance...

salut,

tu passe simplement par une table de liaison

avec une structure du genre:

id, idcommande, idproduit

ce qui te permet d'associer autan de produit que tu veux à une commande...

Salut et merci pour ta réponse :ccool:

Donc en gros :
- une table de jointure pour enregistrer qui passe quelle numéro de commande
- une table de jointure pour regrouper les produits d'une même commande

C'est correct ?
Merci.

c'est l'idée...

:ccool:

Avant de créer des tables, toujours faire un modèle de données !

Le schéma classique est le suivant :
client -0,n----passer----1,1- commande -1,n----concerner----0,n- produit

Ce qui donne, en première approche, les tables suivantes :
client (clt_id, clt_nom...)
commande (cmd_id, cmd_id_client, cmd_date...)
produit (prd_id, prd_reference, prd_nom...)
cmd_concerner_prd (ccp_id_commande, ccp_id_produit, ccp_quantite, ccp_prix_ht...)

Mais si tu dois ensuite gérer les factures et les livraisons qui peuvent ne concerner que certains produits d'une commande (livraisons partielles), alors il faut transformer l'association concerner en entité type "ligne_commande"
client -0,n----passer----1,1- commande -1,n----avoir----(1,1)- ligne_commande -(1,1)----concerner----0,n- produit


Le seul changement est sur la table cmd_concerner_prd qui devient la table :
ligne_commande (lc_id_commande, lc_id_produit, lc_quantite, lc_prix_ht...)

fsmrel dirait aussi qu'il est préférable d'utiliser l'identification relative (cardinalités entre parenthèses qui entraîne la propagation des identifiants entre les tables) carrément depuis le client.
client -0,n----passer----(1,1)- commande -1,n----avoir----(1,1)- ligne_commande -(1,1)----concerner----0,n- produit

Les tables deviennent alors celles-ci :
client (clt_id, clt_nom...)
commande (cmd_id_client, cmd_numero, cmd_id_client, cmd_date...)
produit (prd_id, prd_reference, prd_nom...)
ligne_commande (lc_id_client, lc_numero_commande, lc_id_produit, lc_quantite, lc_prix_ht...)

Ce principe facilite l'écriture de certaines requêtes et est plus performant avec de grosses quantités de données grâce à une économie des jointures dans les requêtes.

Hmmmm, je vois... Merci CinePhil,

Je vois parfaitement ou tu veux en venir, de plus tu as raison, j'aurais du faire une petite analyse avant de foncer tête baissée :/

Néanmoins, en ce qui concerne le prix HT, je pense qu'il devrait se trouver à l'unité dans ma table produits, le prix final pourra être formaté via programmation avant l'affichage, non ?

Merci pour vos réponses en tout cas :ccool:

oui tu peux faire le calcul grace à ce que tu rapatries des jointures...

dans ta table ligne_commande avec la quantité tu as ce qu'il te faut...

après, c'est juste la construction de ta requête qui va te permettre de t'adapter à la structure...

perso je suis aussi assez pour ne pas mettre le prix dans la ligne de commande sauf si c'est déjà ton résultat calculé (prix total pour la ligne en fonction de la quantité) car ça te simplifie alors la requête finale à faire

:ccool:

Citation:

---

Envoyé par nux00

Néanmoins, en ce qui concerne le prix HT, je pense qu'il devrait se trouver à l'unité dans ma table produits, le prix final pourra être formaté via programmation avant l'affichage, non ?

---

Il peut bien sûr y avoir un prix tarif dans la table produit mais un produit peut être vendu à un prix différent du tarif. de plus, quand le prix du produit change, les commandes passées elles ne doivent pas changer. C'est surtout pour ça qu'il faut mémoriser le prix vendu.
On peut :
- directement mémoriser pour chaque ligne le prix unitaire vendu ;
- mémoriser le prix unitaire tarif + l'éventuelle remise accordée sur la ligne de commande, en pourcentage ou en argent.

Il peut aussi y avoir une remise globale sur la commande qui serait donc une colonne de la table commande.

Je suis allé au plus simple dans mon schéma mais bien d'autres choses peuvent être nécessaires dans les tables.

Oui, tu as raison, je voulais commencer simple, c'est pour cela que je n'y ai pas pensé ^^.

Merci pour vos réponses en tout cas :ccool: