Discussion :

[skarno]

Bonjour,

petite question:

je conçois un BD pour une grosse entreprise (+-10 000 pers). J'aimerais intégrer dans la BD de données les personnes qui ont postulé pour l'entreprise mais qui ne font pas partie de celle-ci (+- 90 000 pers).

Dans la mesure ou lorsqu'il s'agit d'une personne faisant partie de l’entreprise, de nombreux champ de type "renseignement administratif" (tél, email pro, fonction, etc ...) doivent être complété. Ces champs seront en revanche inutile, càd vide, pour les 90 000 autres personnes de la BDD.

1° Faut-il faire une table personne physique avec l'ensemble des personnes et tous les champs associées aux personnes physique ou une table personne physique (100 000 ligne) et une table associées employé (10 000 ligne qui point vers la PK table personne physqiue + champs administratifs associés). en d'autres terme dois-je identifierla souspoplation dans un champ de la table principale ou en faire un table liées?

2° Sur quoi se baser pour choisir la meilleur possibilité?

3° de manière générale, que privilégié? l'espace ou un nombre limité de relation (par encodage multiple d'une même info);

4° A vue de nez, access sait-il gérér un tel volume d'informations?


D'avance merci pour vos réponses!

[madefemere]

Bonsoir,

100 000 données ne feront pas plier Access je pense.
Après tout dépendra du but de l'application et de l'utilisation des données.
Moi, je verrai 2 choix :
Choix 1 - Mettre les 100 000 enregistrements dans une seule table avec 1 champ pour identifier si c'est une personne travaillant dans la boîte ou ayant postulé uniquement.
Inconvénient : vous allez à priori conserver des données inutiles (sur les postulants) qui seront utilisés rarement !

Choix 2 - Mettre les 100 000 enregistrements dans 2 tables différentes :
- les 10 000 employés dans la table normale avec tous les détails.
- les 90 000 postulants dans une table Archive (qui peut même être sur une base à part).
Unir les informations des 2 tables uniquement quand on en a besoin. Le reste du temps, n'utiliser que la première table.

Voilà comment je verrai la chose.

Cordialement,

[f-leb]

Bonsoir,

du point de vue de l'organisation des données, le schéma avec deux tables en relation -1----1- est conseillé :


Un employé est une personne physique
Une personne physique peut être un employé

Mais avec ce schéma à deux tables tout se complique avec Access où il faut penser à faire les formulaires...
Mais il n'empêche que si 90% des personnes physiques ne sont pas des employés, un modèle à une seule table est un vrai gruyère (et le fichier grossit inutilement)...

J'avais écrit un truc à une époque sur les relations "un à un" pour les données facultatives...

[skarno]

Ok un tout grand merci pour vos réponses :-)
Si quelqu'un a une idée pour les question 2° et 3°...

[f-leb]

Bonjour,

de nombreux champ de type "renseignement administratif" (tél, email pro, fonction, etc ...) doivent être complété. Ces champs seront en revanche inutile, càd vide, pour les 90 000 autres personnes de la BDD.

Fais le calcul, un champ de type Date c'est 8 octets et imagine un champ "DateEmbauche" renseigné uniquement pour les 10 000 employés. Sous Access les 90 000 DateEmbauche à Null vont quand même occuper 90 000*8=720 Ko (hé oui, même s'il n'y a rien dedans, l'espace est réservé dans le fichier, du moins pour les données numériques). Si tu as de nombreux champs comme ça (des dates=8 octets, des entiers longs comme les clés étrangères=4 octets,...), la taille du fichier augmente inutilement.

Est-ce que les performances vont en pâtir de façon remarquable ? Je n'en sais rien, cela dépend de beaucoup de choses, il faut tester.

Il y a d'autres conséquences aussi. Imagine que la DateEmbauche soit obligatoire à renseigner pour les employés. Si tout est dans la même table, tu ne peux pas interdire les Null (puisque pour les autres cette date n'a pas de sens et doit rester à Null). Il faudra faire gaffe au niveau des formulaires pour rendre la date d'embauche obligatoire pour les employés et l'interdire pour les autres.
Si les employés sont dans une table à part, tu peux mettre "Null interdit" sur ce champ et être un peu rassuré sur la qualité de tes données.

Il y a d'autres trucs comme ça à voir, seulement si tout est dans la même table les traitements/formulaires sont plus simples et certains préfèreront.

Une alternative :
Employe(id, nom, prenom, tel, mail, fonction,...)
AutrePersonne(id, nom, prenom)

des champs sont dupliqués, cela permet aussi d'éviter trop champs à Null

[skarno]

Waouw merci beaucoup pour cette réponse claire et détaillée ! :-)