Discussion :

[Etxezarreta]

Bonjour à tous,
je construis un outil Access pour gérer un projet: il s'agit d'affecter des projets de travail à des personnes: dans la réalité il y a deux types de personnes assez distincts: des soignants et des institutionnels.
La différence se traduit par le nombre de champs différents: par exemple on peut affecter un critère "spécialite" aux soignants ( critère qui sera pertinent pour des recherches ultérieures) , mais qui n'est pas utilisable pour les institutionnels.
Or lorsque j'affecterai les projets aux personnes, je veux pouvoir appeler en même temps les contacts soignants et non soignants (l'utilisateur n'a pas à savoir qu'il y a une différence).
j'ai donc pensé faire deux tables (l'utilisateur aura le choix entre deux onglets de formulaire pour la saisie), et ensuite lorsque j'ai besoin d'appeler les deux types de contacts en même, j'utilise une table alimentée par une requête union sur les champs communs.
J'ai essayé de faire une modélisation sur un excel, le document est en pj.
Ma question est double:
- que pensez-vous de l'organisation des tables? (si mon schéma est compréhensible)
- est-ce une bonne idée de stocker les données ainsi, dans deux tables séparées, ou bien y a t il des arguments pour tout stocker dans une seule et même table, mais en ayant des enregistrements partiellement vides?
Merci d'avance.
Etxe.

[marot_r]

Bonjour.

Voici mon avis court : "Une seule table c'est plus simple".

Plus élaboré.

C'est en contradiction avec une modélisation rigoureuse mais techniquement parlant cela simplifie le modèle et l'exploitation des données.
Il est plus facile de masquer un champs dans un formulaire que de "composer" une source de données.
Et il est très simple de filtrer les données qu'on veut ou pas.

Un modèle très élégant que j'ai croisé est d'avoir 3 tables.

• Une tables pour les champs communs
• Une tables avec les champs spécifiques d'une catégorie
  En relation avec celle des champs communs.
• Une tables avec les champs spécifiques d'une autre catégorie
  En relation avec celle des champs communs.

Cela te permet de n'utiliser qu'une seule source (ex : pour les sélections) et de complémenter au besoin.
Je reconnais que c'est beau mais cela reste, selon moi, pénible à gérer.

Si il n'y a pas beaucoup de champs vides, l'effort ne me paraît pas rentable.

Note que tu peux donner l'illusion à l'utilisateur qu'il travaille avec 2 sources en faisant un formulaire spécifique à chaque source.
Je fais cela dans une de mes applis. J'ai une table de paramètre génériques qui comprend environ 10 champs. Pour la paramétrisation de mes importations je n'ai besoin que de 2 champs donc j'ai créé un formulaire qui n'affiche que ces 2 champs et pas une table avec seulement 2 champs.

A+

[Etxezarreta]

Bonjour Marot,

En effet, peu de champs vides, si nous partons sur une seule table. Je vais voir avec les utilisateurs ce qu'ils en pensent.
Merci beaucoup de ta réponse et de partager ton expérience.

ps: As-tu jeté un œil au modèle de données? Si oui cela te parait-il cohérent pour les autres parties du modèle?
Bonne journée.

[marot_r]

Non je n'ai pas regardé le modèle (pas le droit au téléchargement sur ma machine).

Je te suggère d'ailleurs de plutôt poster une copie d'écran, ça permettra à plus de gens de t'aider (c'est moins de contrainte qu'un fichier joint).

sinon, comme je te l'ai dit, l'utilisateur n'a, à priori, pas besoin de savoir qu'il n'y a qu'une seule table.
C'est une décision d'architecture interne et si tu as fais une bonne interface, il n'en a rien à faire :-).

A+