Aide pour création Bdd client sous Acces
Fermé
batteurkev
-
23 avril 2008 à 20:22
phil_232 Messages postés 286 Date d'inscription jeudi 6 décembre 2007 Statut Membre Dernière intervention 12 juin 2008 - 25 avril 2008 à 23:00
phil_232 Messages postés 286 Date d'inscription jeudi 6 décembre 2007 Statut Membre Dernière intervention 12 juin 2008 - 25 avril 2008 à 23:00
A voir également:
- Aide pour création Bdd client sous Acces
- Orange service client - Guide
- Creation compte gmail - Guide
- Création organigramme - Guide
- Media creation tool - Télécharger - Systèmes d'exploitation
- Tu dois avoir accès au live pour passer live en tant qu'invité - Forum TikTok
2 réponses
phil_232
Messages postés
286
Date d'inscription
jeudi 6 décembre 2007
Statut
Membre
Dernière intervention
12 juin 2008
33
23 avril 2008 à 22:30
23 avril 2008 à 22:30
la relation est fait dans le mauvais sens. CLIENT ne DOIT PAS contenir une réf vers le produit mais PRODUIT doit contenir une vers le client. comme ça chaque achat est lié à un client. puis PRODUIT contient aussi une réf vers le rayon. Donc
CREATE TABLE PRODUIT
[Clé primaire] N°produit (Numérique) ex : 31
ClientID (Numérique),
RayonID (Numérique),
Description produit (Texte) ex : Nike Air blanche
Mettre le prix dans PRODUIT est dangereux ! Souvent on veut un rapport p.ex. à la fin de l'année. Si ton prix à changé dans l'année le chiffre d'affaire ne sera pas correcte. Mieux vaut une table avec les prix avec deux date qui indique leur validité
CREATE TABLE ProductPrice
[Clé primaire] ID (Numérique),
ProductID (Numérique),
Price (Numérique),
ValidFrom DateTime,
ValidTo DateTime
CREATE TABLE PRODUIT
[Clé primaire] N°produit (Numérique) ex : 31
ClientID (Numérique),
RayonID (Numérique),
Description produit (Texte) ex : Nike Air blanche
Mettre le prix dans PRODUIT est dangereux ! Souvent on veut un rapport p.ex. à la fin de l'année. Si ton prix à changé dans l'année le chiffre d'affaire ne sera pas correcte. Mieux vaut une table avec les prix avec deux date qui indique leur validité
CREATE TABLE ProductPrice
[Clé primaire] ID (Numérique),
ProductID (Numérique),
Price (Numérique),
ValidFrom DateTime,
ValidTo DateTime
phil_232
Messages postés
286
Date d'inscription
jeudi 6 décembre 2007
Statut
Membre
Dernière intervention
12 juin 2008
33
25 avril 2008 à 22:56
25 avril 2008 à 22:56
aaaah, en fait j'aurai du y penser. D'abord, non! Ton approche est beaucuop trop lourd pour etre utilisable. Ce qu'on fait c'est un si-dite many-to many. Tu auras trois tables : une pour les clients, une pour les produits, une qui met en relation client et produit. Donc pour CLIENT rien ne change, dans PRODUIT on en ne met PAS la réf vers le client. La 3ième est bêtement
CRATE TABLE ProductsClient
ClientID numérique
ProductID numérique
clé primaire composée de ClientID, ProductID
----------- ------------------- -------------
-Clients- ProductClient Products -
---------- ------------------- -------------
ClientID--ClientID
^^^^^^ProductID -- ProductID
(je voulais faire un ASCII art mais ca marche pas trop bien ici)
en langage humain :
un client peut avoir (acheter) plusieurs produits, et un produit peut etre acheter par plusieurs client, d'où la table qui fait le lein entre les deux
ceci s'appelle Normalisation.
CRATE TABLE ProductsClient
ClientID numérique
ProductID numérique
clé primaire composée de ClientID, ProductID
----------- ------------------- -------------
-Clients- ProductClient Products -
---------- ------------------- -------------
ClientID--ClientID
^^^^^^ProductID -- ProductID
(je voulais faire un ASCII art mais ca marche pas trop bien ici)
en langage humain :
un client peut avoir (acheter) plusieurs produits, et un produit peut etre acheter par plusieurs client, d'où la table qui fait le lein entre les deux
ceci s'appelle Normalisation.
24 avril 2008 à 10:22
Je sais qu'il y a se systeme de liste déroulante avec choix multiples, puis je l'utiliser pour celà ?
24 avril 2008 à 12:27
25 avril 2008 à 23:00
bref : mauvais design