Base de données
Fermé
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
-
20 août 2001 à 18:45
djameleddine - 23 août 2001 à 16:05
djameleddine - 23 août 2001 à 16:05
A voir également:
- Base de données
- Exemple base de données access à télécharger gratuit - Forum Access
- Formules excel de base - Guide
- La base de données de sécurité du serveur n'a pas de compte d'ordinateur pour la relation ✓ - Forum Réseau
- Périphérique système de base ✓ - Forum Pilotes (drivers)
- Tnt base de données vide ✓ - Forum TNT
12 réponses
1-Access ne connaît pas les triggers(sql server , oracle .... OUI ).
2-Access est trés bien pour gérer de "petites choses" et trés accessible au niveau de la programmation
3-Tu parles de gestion des stocks ...... ce qui est certain :
conceptuellement 2 tables seront insuffisantes
- oracle et sql server sont certainement inadaptés à tes besoins
petite question : veux tu gérer un historique de tes stocks et/ou des lignes de produits vendues
- access semble être adapté à ce que tu veux faire.
même s'il n'y a pas de triggers il suffit de taper un bout de code pour effectuer la mise à jour du stock automatiquement.
Si tu veux gérer un historique de tes stocks et/ou des lignes de produits vendues il faut revoir ton analyse au niveau du nombre de table
petit exemple :
avec ta table article (telle que tu me la decrite ) un article ne peut avoir qu'un seul prix de vente.
Il te faut donc une table
voici une solution (parmi d'autre ) :
PK : primary key
FK: foreign key
'table pour garder un historique des tarifs
HIST_TARIF (ID,PRIX,DATE-HEUR-MIN-SEC,ID_ARTICLE)
PK : ID ((autoincréménté)) + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE
'table pour enregistrer tes articles
ARTICLES (ID_ARTICLE, LIBELLE, DESCRIPTION)
PK : ID_ARTICLE (autoincréménté)
'table pour l'historique des stocks
STCK (ID_ARTICLE, DATE-HEUR-MIN-SEC , QUANTITE DISP )
PK : ID_ARTICLE + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE
'table pour enregistrer les ventes
VENTE (ID_VENTE,DATE-HEUR-MIN-SEC, ID_ARTICLE, RABAIS)
PK : ID_VENTE (autoincréménté)
FK : ID_ARTICLE
IL N'Y A PAS QUE CETTE SOLUTION
il faut en fait que tu analyse tes besoins en relevant toutes les informations que tu veux récupérer (prix , libéllé article,...)
Et seulement après tu commence la conception ........... et beaucoup plus tard ton dev
@+
A.N
même s'il n'y a pas de triggers il suffit de taper un bout de code pour effectuer la mise à jour du stock automatiquement.
Si tu veux gérer un historique de tes stocks et/ou des lignes de produits vendues il faut revoir ton analyse au niveau du nombre de table
petit exemple :
avec ta table article (telle que tu me la decrite ) un article ne peut avoir qu'un seul prix de vente.
Il te faut donc une table
voici une solution (parmi d'autre ) :
PK : primary key
FK: foreign key
'table pour garder un historique des tarifs
HIST_TARIF (ID,PRIX,DATE-HEUR-MIN-SEC,ID_ARTICLE)
PK : ID ((autoincréménté)) + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE
'table pour enregistrer tes articles
ARTICLES (ID_ARTICLE, LIBELLE, DESCRIPTION)
PK : ID_ARTICLE (autoincréménté)
'table pour l'historique des stocks
STCK (ID_ARTICLE, DATE-HEUR-MIN-SEC , QUANTITE DISP )
PK : ID_ARTICLE + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE
'table pour enregistrer les ventes
VENTE (ID_VENTE,DATE-HEUR-MIN-SEC, ID_ARTICLE, RABAIS)
PK : ID_VENTE (autoincréménté)
FK : ID_ARTICLE
IL N'Y A PAS QUE CETTE SOLUTION
il faut en fait que tu analyse tes besoins en relevant toutes les informations que tu veux récupérer (prix , libéllé article,...)
Et seulement après tu commence la conception ........... et beaucoup plus tard ton dev
@+
A.N
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
1
21 août 2001 à 17:41
21 août 2001 à 17:41
Merci pour ta réponse. MAis en fait je crois que je n'ai pas besoin d'autant de table, car un article n'a qu'un prix de vente au départ, il est stocké dans la table article, et si il y a des soldes ou un rabais, le prix de vente réel est stocké dans la table vente ...
Je ne pense pas avoir besoin d'une table d'historique des stocks.
Comment est-ce q
Je ne pense pas avoir besoin d'une table d'historique des stocks.
Comment est-ce q
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
1
21 août 2001 à 17:43
21 août 2001 à 17:43
Merci pour ta réponse. MAis en fait je crois que je n'ai pas besoin d'autant de table, car un article n'a qu'un prix de vente au départ, il est stocké dans la table article, et si il y a des soldes ou un rabais, le prix de vente réel est stocké dans la table vente ...
Je ne pense pas avoir besoin d'une table d'historique des stocks.
Comment est-ce que je défini une clé étrangère dans Access ? Et comment je défini un clé primaire qui a 2 attributs ?
Et si je dois ajouter du code pour pouvoir mettre à jour le stock ça sera en VB n'est-ce pas ? Je connais rien de rien au VB, ça ressemble un peu au C, ou a JAVA par hasard ???
a+
SEB
Je ne pense pas avoir besoin d'une table d'historique des stocks.
Comment est-ce que je défini une clé étrangère dans Access ? Et comment je défini un clé primaire qui a 2 attributs ?
Et si je dois ajouter du code pour pouvoir mettre à jour le stock ça sera en VB n'est-ce pas ? Je connais rien de rien au VB, ça ressemble un peu au C, ou a JAVA par hasard ???
a+
SEB
ce sera du VBA sous access
non non c'est pas du C
L'apprentissage est beaucoup plus rapide.
Tu ne connait certainement pas le SQL :
en utilisant l'interface graphique pur créer une clé primaire il faut sélectionner le champ et cliquer sur l'icône qui represente une clé jaune. (si ta clé comporte plusieurs champs il tous les séléctionner ).
pur la clé étrangére il faut définir des relations
non non c'est pas du C
L'apprentissage est beaucoup plus rapide.
Tu ne connait certainement pas le SQL :
en utilisant l'interface graphique pur créer une clé primaire il faut sélectionner le champ et cliquer sur l'icône qui represente une clé jaune. (si ta clé comporte plusieurs champs il tous les séléctionner ).
pur la clé étrangére il faut définir des relations
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
1
21 août 2001 à 18:29
21 août 2001 à 18:29
Si je connais le sql justement, ça m'aurait plu de pouvoir construire mes tables en sql. Je suis débutant, ça m'aurait entraîner.
CREATE TABLE ARTICLE
(
ID COUNTER CONSTRAINT PrimaryKey PRIMARY KEY,
LIBELLE TEXT (60),
.................
.................
)
CREATE TABLE HIST_TARIF
(
ID ............ <------- pk
ID_ART ............. <------- fk
)
ALTER TABLE HIST_TARIF
ADD CONSTRAINT ID_FK FOREIGN KEY(ID) REFERENCES ARTICLE(ID)
(
ID COUNTER CONSTRAINT PrimaryKey PRIMARY KEY,
LIBELLE TEXT (60),
.................
.................
)
CREATE TABLE HIST_TARIF
(
ID ............ <------- pk
ID_ART ............. <------- fk
)
ALTER TABLE HIST_TARIF
ADD CONSTRAINT ID_FK FOREIGN KEY(ID) REFERENCES ARTICLE(ID)
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
1
21 août 2001 à 21:40
21 août 2001 à 21:40
Merci... mais est-ce que je peux insérer ça dans Access pour que çA me génère les tables ?
Et comment je fais pour aller voir le code des la création de mes tables dans Access ? Où c'est que je peux rajouter du code pour pouvoir faire diminuer mon stock ?
Et comment je fais pour aller voir le code des la création de mes tables dans Access ? Où c'est que je peux rajouter du code pour pouvoir faire diminuer mon stock ?
est-ce que je peux insérer ça dans Access pour que çA me génère les tables ?
----->oui tu peux exécuter directo du sql dans l'onglet des requêtes
pour ce qui concerne ton autre question :
tu devras sans doutes utiliser les formulaires.
il faut utiliser soit des macros soit des procédures écrites en VBA
précision : les macros c'est plus lent
----->oui tu peux exécuter directo du sql dans l'onglet des requêtes
pour ce qui concerne ton autre question :
tu devras sans doutes utiliser les formulaires.
il faut utiliser soit des macros soit des procédures écrites en VBA
précision : les macros c'est plus lent
Si j'étais à ta place, avant de me lancer dans la conception et la réalisation d'une première appli sous Access, je ferais un ou deux tutoriels pour bien prendre en main l'outil : tu sembles hésitant (où faire du SQL directement ? étapes de création d'un formulaire, pourquoi créer des requêtes, attribuer du code VB à des éléments de formulaires, etc...), et ce genre d'hésitations fait perdre du temps, risque d'amener à faire des boulettes, etc...
Cela te permettra en plus de te familiariser avec l'EDI de VBA.
Tittom
Cela te permettra en plus de te familiariser avec l'EDI de VBA.
Tittom
rezzoni0
Messages postés
48
Date d'inscription
dimanche 24 juin 2001
Statut
Membre
Dernière intervention
27 juin 2003
1
22 août 2001 à 16:46
22 août 2001 à 16:46
Merci à tous pour vos réponses, je vais essayer tout ça et on verra bien
a+
sEb
a+
sEb
20 août 2001 à 20:06
ARTICLE(num_article//description,stock_debut,stock_actuel, prix_achat,prix_vente)
et
VENTES(num_article, num_vente//date_vente,quantite,rabais,prix_final)
num_article est la clé primaire d'ARTICLE, et est clé étrangère de ventes ? c'est comme ça que je fais la jointure non ?
Ca me suffit ces 2 tables il me semble ...
SQL Server et Oracle sont de gros programmes non ? Ils vont tourner difficilement sur un portable avec 64Mo de ram ....