Re : Schéma relationnel : Gestion client: suivi/devis/facture
Bonjour
Il faut distinguer 2 choses :
- la liste des domaines d'activité qui est une table de référence
- la tables des domaines des clients qui est une table de jointure entre clients et domaines et qui a comme clé primaire la combinatoire N° client+ID domaine.
- La tables des domaines des clients (N) est en relation avec
- la table de référence(1) avec intégrité référentielle
- la table des clients (1) avec intégrité référentielle
- il faut remplir le table de référence avant de saisir les clients.
- dans la structure de la table des domaines des clients on peut indiquer que le champ domaine est contrôle par le table de référence et qu'il y a une liste déroulante.
Ainsi quand tu crées les formulaires, les listes déroulantes et le contrôle est en place
Il y a la même logique pour les services. De façon générale, on distingue pour les devis et/ou factures la table des devis (ou factures) où figurent les infos n'existant qu'une fois, de la table des lignes de devis ((ou factures) ou figurent les infos de la ou des lignes. (Prix U, qté notamment).
Toutes les relations doivent être de 1 à N avec intégrité et sans mise à jour en cascade. Sauf Access permet cela, pas les gros SGBD et dans une appli "officielle" (facturation), tu risques d'être hors la loi puisque cette option autorise de modifier des identifiants.
Pour l'ordre requêtes ou formulaire, globalement c'est formulaires d'abord amis il faut d'abord : lister toutes les interfaces nécessaires, celles qui servent à la saisie, celles qui servent à la consultation simple ou basée sur une analyse plus poussée, puis les documents d'exploitation (états).
Les formulaires de saisie ne nécessitent pas de requêtes, ou éventuellement intégrées à certains champs.
Les requêtes alimentent surtout les états et, selon les besoins, certaines interfaces de consultations.
L'idée d'une table documents est effectivement une piste : bien approfondir les besoins, les documents concernés avant de trancher.