Gestion de statistiques dans une BDD existante

**azertix** · 11/01/2010, 17h02

Bonjour à tous.
Je n'ai pas de problème particulier, je recherche surtout des conseils avisés afin de partir sur la meilleure solution de développement possible.

J'ai un applicatif déjà existant avec une base de données assez classique dont voici la structure :

Comme vous pouvez le constater, il s'agit de gérer des notes de liaison concernant des contrats réalisés par des vendeurs en agence.
Les contrats invalides sont renvoyés en agence par les employés du service accompagnés d'une note comportant le motif du retour.
Les notes font l'objet d'une ou plusieurs relances si le contrat corrigé n'a toujours pas été envoyé par l'agence au bout d'un mois.

Bref, on me demande à présent de réaliser des statistiques concernant ces notes :
- Liste des agences avec pour chacune le nombre de retours (=nombre de notes) dans le mois x.
- Nombre de retours pour chaque motif concernant l'agence x pour le mois et l'année y.

La structure actuelle de ma base de données me permet d'obtenir ces informations.
Le problème est qu'une fois le contrat valide, la note correspondante est supprimée par les employés.
Donc si je basais mes statistiques là-dessus, elle ne prendraient pas en compte les notes supprimées.

J'en viens enfin à ma question : comment gérer ces statistiques de la façon la plus judicieuse possible (ajout d'une table ? si oui comment la relier au système d'information existant ?) ?

Merci d'avance à ceux qui me liront.

**Jean-Philippe André** · 12/01/2010, 11h20

salut,
la suppression des enregistrements lors de leur fin de vie n'est pas forcément la solution la plus efficace, la preuve en est pour ta génération de statistiques.

Le plus "simple" serait dans un premier temps d'ajouter un champ dans la table Notes de type booléen, nommé par exemple bTermine, qui reflète le fait que la note soit encore active ou pas.

Les utilisateurs auraient juste à cocher ce champs pour indiquer que la note est arrivée à son terme.

Tu pourras dès lors générer des statistiques sur les notes historiques ou sur les notes actives.

Cette approche te convient-elle ?

**azertix** · 12/01/2010, 12h01

Et bien figure-toi que quand j'avais conçu l'application l'an dernier, j'avais créé mon appli comme ça. Il y avait un champ de type booléen qui indiquait si la note était validée ou pas et un bouton sur le formulaire permettait de changer cet état.
Le responsable du pôle, m'avait alors dit que c'était plus simple de les supprimer et que ça faisait double emploi (j'avais mis aussi la suppression).
Comme quoi mon idée n'était pas si mauvaise

Écoute, je vais voir si on peut gérer ça comme ça.
Le problème habituel se pose cependant : la taille de la base !
Dis-toi qu'il a eu environ 3600 notes réalisées en deux ans. Donc la taille de la base de données va rapidement augmenter si les notes sont conservées ...
Tu aurais une astuce ? (archivage ?)

Merci de ta réponse et bon appétit

**Jean-Philippe André** · 12/01/2010, 12h05

S'il y a 3600 enregistrements "seulement" créés en 2 ans, tu n'es pas non plus à la limite que peut supporter Access

Si vraiment tu ressens le besoin de prévoir large, il est toujours possible :
- soit de stocker les informations sur une base plus robuste (SQL Server, Oracle, etc.), avec la table reliée en ODBC dans ta base Access
- soit de faire une mise à niveau avec des suppressions massives à intervalles réguliers
- soit de faire une extraction régulière des données dans un format compact, avec suppression de la base frontale...

**azertix** · 12/01/2010, 13h14

Quelles sont les limites d'Access en terme d'enregistrements et de taille du fichier mdb ?
Parce que les 3600 enregistrements dont je parlais ça ne concernait qu'une seule table (NOTES). Il y a beaucoup plus de contrats et de clients. Sans compter les autres tables.
A quoi on s'expose avec une BDD grossissante ? (ralentissements ? plantages ?)
Il y a des méthodes propres et sûres pour nettoyer une base de données ? (par exemple reprendre les NumAuto à zéro ?)
Désolé pour toutes ces questions, mais je préfère connaitre les risques avant d'entreprendre quoi que ce soit