Discussion :

[arno2000]

Bonjour,

Je suis en train de développer une base access pour gérer les temps au tour des pilotes et le classement pour chaque course.

Ca fait plusieurs jours que je cherche une bonne solution pour résoudre mon nombre de champs dans une table (table classement) mais à force de chercher je remets mon travail de conception en question.

Cette table contient environ 50 champs (position, nb. tour, meilleur tour, écart avec le précédent ...) et je voulais savoir si ca risquait de poser problème pendant l'utilisation ?

Ces champs sont pour la plupart des champs "calculés" depuis une autre table (table passages). Je sais que normalement on ne doit pas mettre de champs calculés mais là je dois pouvoir afficher les info rapidement pour une course sélectionnée. Je précise que cette base access sera utilisé avec le .NET 2005.

Si je devais calculer les champs à chaque fois, cela pourrait prendre plusieurs secondes suivant la taille de la table "Passages" et ça ce n'est pas possible.

Pouvez vous m'aider ?

Merci

[cafeine]

Hello,

il n'est pas totalement aberrant de stocker une table de ratios / stats en fin de process pour pouvoir facilement et rapidement consulter des résultats.

50 champs ne posent pas de problème, la limite est de 255 ...
quel est le niveau le plus fin ?
- par pilote / tour
- par pilote / course
- par pilote / saison ?
- que sais-je ?

[arno2000]

merci cafeine pour ta réponse.

Je pense que l'ideal dans mon cas est d'avoir le résultat par pilote / course.

Donc si c'est pas aberrant comme solution, je fonce car mes cours de base de données sont loin et je n'étais pas très fort à l'époque ...

Merci

PS : Je laisse le post ouvert quelques jours s'il y a d'autres commentaires

[cafeine]

Non l'idée c'est de ne pas stocker dans ce cas des ribambelles de tables de calculs intermédiaires, mais uniquement des calculs en niveau agrégés ...
ça ne choque pas mon sens assez peu orthodoxe des bases de données ...

les experts parleront ...

[random]

50 champs pour une table de synthèse cela me parait beaucoup
si j'ai bien compris il existe des informations au passage, à la course, au pilote
le problème n'est pas de de calculer l'information de synthése
mais de la présenter sous une forme assimilable
qui peut garder à l'esprit plus de 10 ou 12 paramètes?

je travaillerais d'abord sur une présentation synthétique en ciblant
bien l'information ultime utile et visuellement parlante

à partir de celle ci il doit être possible de manière interactive de chercher
les explications aux phénomènes qui apparaissent à l'écran

ceci suppose des requêtes de second niveau paramétrées et donc sur
des volumes réduits

[arno2000]

En fait voila le principe :

J'ai des pilotes qui font des passages (des tours de circuit)
--> C'est ma table Passages

Une fois la course terminée, j'ai un classement suivant le nombre de tours réalisé par chaque pilotes. (le 1er est celui qui a le plus de tours)
--> C'est ma table Résultats

Dans ma table Passages, je stocke le temps au tour, l'heure du passage et l'ID du Resultat du pilote

Dans ma table Résultats, je stocke l'id du résultat, le nom du pilote, sa catégorie, sa position, le nb de tours, l'écart avec le 1er, l'écart avec le précédent, le meilleur tour ... (le tout fait 50 champs environ)

J'espère que c'est plus clair.

Le problème c'est que je dois afficher le classement en temps réel, c'est pour ça que je pensais mémoriser le classement dans la base. Car s'il y a beaucoup de passages, ça risque d'être couteux de recalculer les "stats" de chaque pilote dans la course à chaque fois qu'un pilote fait un tour ...

Si vous avez d'autres commentaires

[Tofalu]

Bof, les calculs me semblent pas trés complexes, pour moi, la table de résultat ne se justifie pas. Une série de requête sur la table Passage ferait l'affaire selon moi