Je vais etre amené à construire une boutique en ligne de base (genre avec un caddie, des articles, eventuellement des promos etc etc)
je suis en train de reflechir sur les tables SQL, malgré la simplicité que ça a l'air d'être... il faut pas se planter à ce moment là...
 
pour l'instant je propose :
 
une table client qui renseigne toutes les infos du client avec un numéro de client unique
 
une table facture qui contient le numero de la facture, le numero du client, le numero d'article, la quantité, les infos sur le paiement et les infos sur la livraison (en gros)
(un enregistrement se faire à chaque article commandé, donc il peut y avoir plusieurs enregistrements pour la même commande)
 
uen table articles contenant le numero de l'article, le libellé, la description, le prix en euros, le prix en dollars, la promo eventuelle, la disponibilité, les frais de ports EUR et US
 
on peut faire la jointure de ces trois tables par l'id lui correspondant...
 
à votre avis... est-ce que je suis sur la bonne voie ou j'ai tout faut et ça risque de se vautrer rapidement ? ai-je oublié des élements importants ?
 
Merci d'avance
 
Freed

Salut,
 
le seul truc que je trouve un peu bizarre c'est que pour une même commande tu auras autant de N° de factures que de produits commandés.  
 
Donc à ta place je ferais :
COMMANDE [numcommande, numclient,infos_paiement, infos_livraison, ...]
 
L_COMMANDE [num_article,num_commande, quantite,...]
 
Pour le reste je vois pas ce qui pourrait merder.

donc deux tables pour les commandes ?
une qui gere la facture et l'etat de la commande, et une qui gere son contenu ?

Non, une "commande" et une "ligne d'une commande"

ah ok je capte bien... merci pour les infos !

Au faite! n'utilise pas le mot caddie mais panier Caddie est une marque .
Fait une model de données tu aurais les idées plus claire. Ne la fais pas a l'américain mais a la russe c'est a dire un stylo et du papier pas la peine d'un logiciel.
 
 
 
 
 
 
 
 
 

Oulà, si c'était si simple, je serais le plus heureux des hommes
 
Sinon, oui, séparez commande et ligne de commande est une très bonne idée (n'oublie pas de stocké le prix de l'article dans la ligne de commande en passant). Puis suivant le type d'article que ta boutique peut contenir, je te conseillerais aussi une séparation article <> détail_article (hyper utile pour du matériel informatique ou des livres par exemple).
 
Voilà

...mais en gardant en mémoire que ceci n'est qu'une copie à l'instant T du prix indiqué dans la table des articles!

 
Ouais, enfin, en général, le prix d'un article est celui au moment de la commande, pas celui à la livraison. Je pourrais te tartiner pendant des heures sur des cas où ce genre de petit détail a été oublié dans la conception des db

Ben...c'est ce que je dis, non?

Euh, oui, le smiley m'a trompé

Par contre je capte pas trop pourquoi on sépare l'article de son detail ?

Pour permettre une recherche sur certaines caractéristiques lorsque tes articles en ont un nombre variable (bon, à nouveau, ça dépend de ce que tu mets dans ta boutique ).
 
Par exemple, comment fais tu une recherche style "je veux toutes les cartes graphiques de marque Asus possédant une entrée TV et 256 Mo de Ram vidéo" avec juste un champs description dans une table contenant tes articles informatiques ?
 
Avec la séparation, c'est juste une recherche des valeurs dans la table détail

ah okok ! j'avais pas compris ça comme ça ! je pensais que tu faisais une deuxieme table pour les articles !
 
dans mon cas je crois qu'il n'y a pas besoin de trop decouper la description de mes articles... on devrait pouvoir s'en passer

 
3 au total en fait

3 tables ????   alors là je sèche !

 
Je sais
 
En gros et sans entrer dans les détails :
 
une table produit(idproduit,libellé,idfournisseur,...)
une table detailProduit(idDetail,intitulé,unité)
une table relDetailProduit_Produit(idProduit,idDetail,valeur)
 
En pratique, ça pourrait donner un truc genre
Produit
-------
1 kkwet 123 ...
 
detailProduit
-------------
1 Prix €
2 Prix $
3 Poids Kilo
relDetailProduit_Produit
------------------------
1 1 1
1 2 1.07
1 3 0.23
 
Ca nous donne un article kkwet avec un prix de 1 € ou 1.07 $ et pesant 0,23 kilo (exemple bidon, c'est pas la meilleure façon de faire pour les prix dans des devises différentes, mais soit)

mouai je suis pas convaincu là... :-/
 
deux tables ok.. Mais trois....

Ben pourtant là on touche aux bases de la modélisation de données

je sais j'ai fais des cours de modelisation (normalisation) avec les trucs de merise etc etc... mais je comprends pas les 3 tables

je commence à piger... mais en fait c les chiffres qui m'embrouillaient l'esprit... j'essaie de faire les relations entre les trois tables et je comprenais rien !

Comment veux-tu faire une association m-n entre deux tables sans passer par une troisième ?

 
Arf, j'ai failli mettre le mcd, mais devant l'hésitation sur les 3 tables, je me suis dit que ce serait encore plus abstrait

bah ouai et moi j'essayais (et j'essaie toujours) d'imaginer le mcd !! mais bon.. je devrais peut etre le faire avec un stylo et une feuille plutot que de me fier a mon petit cerveau !

peut être... c'est toujours bon de faire un schéma sur papier.

 
bon voila j'ai tenté de faire un MCD... j'ai pas trop l'habitude de ça (en fait j'en ai fait que pendant 3 jours alors pas facile de toute capter)
 
voila ce que ça me donne :
 
http://www.clonecopy.net/freed/MCD.jpg
 
dites moi ce que vous en pensez, j'ai surement oublié des trucs... et je suis pas sur de moi sur les cardinalités et les actions... bref... c plus un exercice pour moi qu'autre chose mais ça peut toujours servir !  

Bon, en vrac et sans fouiller profondément, quelques trucs que j'ai noté :
 
Il est toujours utile dans le cas d'une boutique en ligne d'avoir l'adresse email du client (j'aurais vraiment envie de te pourrir la vie, je te dirais de faire une table à part pour les contacts, histoire d'avoir aussi plusieurs n° de téléphone pour tes clients )
 
Pense aussi au fait que tu peux ne pas faire toute la livraison de la commande en une seule fois, et donc avoir plusieurs factures partielles pour une commande. il manque d'ailleurs le suivi de la commande dans ton MCD : pas de facture, pas de vérification de payement, c'est gênant
 
Je comprends pas trop l'intérêt de la structure Produits-rel_Detail_Produits-detail_produits telle que tu la définis là, uniquement des relations 1-1, je sens la mauvaise interprétation de ce que je t'ai dit plus haut
 
Voilà, je vais essayer de voir si j'ai pas encore un modèle qui traine pour ce genre de truc, pour voir si j'ai rien oublier en survolant le tien

Pour un stage j'ai fait une boutique en ligne.
Voila le modèle de données (à l'arrache) :

 
Les tables transporteur et assoc_cat_transporteur, laisse tomber, c'était un truc spécifique à ma boutique (possiblité d'ajouter des transporteurs avec des règles de calcul de prix)
 
 
Y'a une version de démo de la boutique ici : http://aujardindedgar.free.fr/plantes-du-mois.php
 
Et la partie administration là :  
http://aujardindedgar.free.fr/admin/index.php

 
Je suis tout à fait d'accord avec toi... mais j'ai pas detaillé les contenu de mes entités... j'ai surtout focalisé sur les entités et les relations.. apres je dois forcement penser à creuser un peu.. là pour l'instant j'ai mis dans mes tables que ce qui me venait à l'esprit sans trop me creuser les meninges
 

 
Là c même réponse que précedement... et tu pourras noter que pour le suivi des commandes j'ai ajouté un champ "livraison" et "paiement" qui insinuait que je compte bien donner un état à ce niveau là... (je l'ai ecrit dans le cahier des charges mais vous ne l'avez pas lu ! )
Quand à la facture partielle... je n'y ai pas pensé.. mais là c pas dans le cahier des charges ! (on suppose que une livraison se fait en une seule fois (à defaut de rupture des stocks mais c censé etre bien géré !) par contre on peut livrer à des adresses différentes de celle du client, ainsi que la facturation qui peut etre différente... d'où les deux tables addr_livraison et addr_facturation
 

Là c possible que j'ai mal interprété... enfin je l'ai comprise dans un sens... peut etre que je me suis planté !

Merci pour tout en tous cas... je fais tout ça un peu pour revenir à l'essentiel, je me suis trop pris de gamelles avec un boss un peu trop impulsif qui croit qu'on peut changer tout dans un site tous les 3 jours et qui râle à la fin parceque c'est pas terminé 15 jours apres la signature du devis par le client! lol ! ya de quoi halluciner ! alors maintenant c moi qui fait les devis et le cahier des charges ! (mais c pas trop mon truc!)