Dilemme de nombre de tables dans Access
Résolu
sipherion
Messages postés
1809
Date d'inscription
Statut
Membre
Dernière intervention
-
sipherion Messages postés 1809 Date d'inscription Statut Membre Dernière intervention -
sipherion Messages postés 1809 Date d'inscription Statut Membre Dernière intervention -
A voir également:
- Dilemme de nombre de tables dans Access
- Nombre de jours entre deux dates excel - Guide
- Ascii nombre de caractères - Guide
- Tables des matières word - Guide
- Nombre facile - Télécharger - Outils professionnels
- Nombre de page - Guide
5 réponses
Le découpage en plusieurs tables se fait sur la base des colonnes et non sur la base des lignes. Tu n'auras jamais une table par personnes, mais plutôt une personne répartie sur plusieurs tables.
Si tu pars d'un fichier Excel simple, je te conseil une seule table. Plusieurs table pourraient par exemple se justifier si tu gerais les historiques des adresses des personnes. Mais cela complique la conception de la base...
Si tu pars d'un fichier Excel simple, je te conseil une seule table. Plusieurs table pourraient par exemple se justifier si tu gerais les historiques des adresses des personnes. Mais cela complique la conception de la base...
Salut,
les informations et sous-informations gérées peuvent-elles être les mêmes ?
Ou d'une autre façon : une personne peut-elle partager une information/sous-information avec une autre ?
les informations et sous-informations gérées peuvent-elles être les mêmes ?
Ou d'une autre façon : une personne peut-elle partager une information/sous-information avec une autre ?
Allez, je vais essayer de passer un peu plus d'infos :
En fait, il s'agit d'agents dans un centre d'appels. Pour effectuer un suivi de la qualité, notre service interne effectue des écoutes.
Une écoute est faite sur un agent pour un projet spécifique, projet qui appartient à un pôle d'activités.
Une écoute se fait sur 50 critères maximum.
Donc oui, on va retrouver pour chaque agent des notes différentes, mais sur énormément de critères communs.
J'avoue que je suis également un peu perdu pour établir son merise, vous pourriez peut être m'aider ;-)
En fait, il s'agit d'agents dans un centre d'appels. Pour effectuer un suivi de la qualité, notre service interne effectue des écoutes.
Une écoute est faite sur un agent pour un projet spécifique, projet qui appartient à un pôle d'activités.
Une écoute se fait sur 50 critères maximum.
Donc oui, on va retrouver pour chaque agent des notes différentes, mais sur énormément de critères communs.
J'avoue que je suis également un peu perdu pour établir son merise, vous pourriez peut être m'aider ;-)
D'après ce que je lis, je verrais les tables suivantes :
- pole (numpole, nompole)
- projet (numprojet, nomprojet)
- agent (numagent, nomagent)
- ecoute (numecoute_auto,date,duree, auditeur,numprojet,numagent)
- notes (numnote_auto, numcritere, note,numecoute)
notes sera liée uniquement à écoute
écoute sera liée à notes, agent et projet
Mais après, il faut voir ce qu'on veut faire des informations qu'on traite...
- pole (numpole, nompole)
- projet (numprojet, nomprojet)
- agent (numagent, nomagent)
- ecoute (numecoute_auto,date,duree, auditeur,numprojet,numagent)
- notes (numnote_auto, numcritere, note,numecoute)
notes sera liée uniquement à écoute
écoute sera liée à notes, agent et projet
Mais après, il faut voir ce qu'on veut faire des informations qu'on traite...
Merci pour ce premier jet, ça m'a l'air déjà très intéressant.
Je dois etre capable de tout faire avec ces données : afficher un résumé par agent, par pôle, par projet, par agent par projet. Quand le formulaire est remplit, je suppose que je dois faire une requête SQL pour chaque table, idem pour afficher les résultats.
Je dois etre capable de tout faire avec ces données : afficher un résumé par agent, par pôle, par projet, par agent par projet. Quand le formulaire est remplit, je suppose que je dois faire une requête SQL pour chaque table, idem pour afficher les résultats.
Bon, j'ai établi mes tables selon une proposition de Merise, et je voulais voir si quelqu'un avait une autre idée, car dans ce contexte, on aurait pour, au maximum :
120 agents à écouter ;
20 écoutes par agent par mois, soit 2.400 écoutes par mois ;
50 critères à noter par écoute, soit 120.000 critères par mois.
Dans ce système, on aurait donc dans la table notes 120.000 lignes par mois, et dans la table ecoutes 2.400 lignes par mois.
Dans l'idéal, il me faudrait une base de données Access par année, mais là on atteint des chiffres astronomiques.
Quelqu'un pourrait me proposer une solution ? Je patauge un peu là... :/
Rappel du Merise :
- pole (numpole, nompole)
- projet (numprojet, nomprojet, numpole)
- agent (logagent, nomagent)
- ecoute (numecoute_auto,date, auditeur,numprojet,logagent)
- notes (numnote_auto, numcritere, note,numecoute)
Que pensez vous de concaténer ecoute et notes en faisant par exemple :
- ecoute (numecoute_auto,date, auditeur,numprojet, logagent, critere1, note1, critere2, note2, critereN, noteN)
Si votre problème est résolu, merci de clôturer le sujet en cliquant sur "Problème résolu".
Administrateur réseaux sous Windows Serveur 2003
120 agents à écouter ;
20 écoutes par agent par mois, soit 2.400 écoutes par mois ;
50 critères à noter par écoute, soit 120.000 critères par mois.
Dans ce système, on aurait donc dans la table notes 120.000 lignes par mois, et dans la table ecoutes 2.400 lignes par mois.
Dans l'idéal, il me faudrait une base de données Access par année, mais là on atteint des chiffres astronomiques.
Quelqu'un pourrait me proposer une solution ? Je patauge un peu là... :/
Rappel du Merise :
- pole (numpole, nompole)
- projet (numprojet, nomprojet, numpole)
- agent (logagent, nomagent)
- ecoute (numecoute_auto,date, auditeur,numprojet,logagent)
- notes (numnote_auto, numcritere, note,numecoute)
Que pensez vous de concaténer ecoute et notes en faisant par exemple :
- ecoute (numecoute_auto,date, auditeur,numprojet, logagent, critere1, note1, critere2, note2, critereN, noteN)
Si votre problème est résolu, merci de clôturer le sujet en cliquant sur "Problème résolu".
Administrateur réseaux sous Windows Serveur 2003
Ca ne va pas résoudre ton problème : tu auras moins de lignes, mais plus d'espace qui ne sert à rien, puisque tu devras créer 2 x colonnes par critère, qu'elles soient utilisées ou non...
Access sait gérer sans trop de problème des tables de plusieurs millions de lignes en restant en-deça de la taille limite du fichier .mdb fixée à 2 Go.
On peut peut-être simplifier en mettant les notes dans une chaine de caractère avec un positionnement qui est spécifique au critère...
Access sait gérer sans trop de problème des tables de plusieurs millions de lignes en restant en-deça de la taille limite du fichier .mdb fixée à 2 Go.
On peut peut-être simplifier en mettant les notes dans une chaine de caractère avec un positionnement qui est spécifique au critère...
Si je comprends bien, ce serait donc concaténer les deux chaines et faire un truc du style :
- ecoute (numecoute_auto,date, auditeur,numprojet, logagent, liste_criteres, notes_criteres)
Et des résultats qui s'inscrivent dans les deux dernières colonnes :
{crit1; crit2; crit3; ...; crit50} {note1; ;note3; ...; note50}
Ou même enlever liste_critères pour ne garder que les notes
- ecoute (numecoute_auto,date, auditeur,numprojet, logagent, liste_criteres, notes_criteres)
Et des résultats qui s'inscrivent dans les deux dernières colonnes :
{crit1; crit2; crit3; ...; crit50} {note1; ;note3; ...; note50}
Ou même enlever liste_critères pour ne garder que les notes
Oui, et comme je l'ai dit, ne garder que les notes, en considérant qu'une note est placée toujours au même endroit en fonction de son critère.
12;14;;15;18...
ici, critère3 n'a pas été évalué, sous-entendu que critère3 est le même pour toute écoute. Il suffit de rajouter une table qui nomme les critères de manière intelligible.
Ca peut tenir dans une chaine standard d'access (max 255 car), mais ça fera quand même un sacré paquet de traitement de manipulation de chaines, va falloir écrire des fonctions pour ça...
12;14;;15;18...
ici, critère3 n'a pas été évalué, sous-entendu que critère3 est le même pour toute écoute. Il suffit de rajouter une table qui nomme les critères de manière intelligible.
Ca peut tenir dans une chaine standard d'access (max 255 car), mais ça fera quand même un sacré paquet de traitement de manipulation de chaines, va falloir écrire des fonctions pour ça...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question