Structure d'une Bd MySQL

Bonjour,
Dans le cadre d'un projet, j'aimerais avoir votre avis sur la structure de la base de données que je devrais utiliser.

Le projet est un programme autonome (Delphi) qui enregistre les changements d'états d'un moteur (M quand le moteur fonctionne, A lorsqu'il est à l'arret et I lorsque son état est incertain, environ 20 changements par jour). Pour chaque changement d'état, j'enregistre la date, l'heure et l'état du moteur (M, A ou I).

Chaque moteur se situe dans des batiments différents mais un batiment peut possèder plusieurs moteurs. Au final mon programme gèrera au maximum 600 moteurs et l'historique de recherche est de 5ans environ.

J'aimerais savoir quelle architecture auriez-vous utilisé pour que lors d'une requête, le temps de reponse soit raisonnable et l'architecture le plus logique possible. A votre avis, dois-je dédier une table par moteur ou bien dois-je tout mettre dans la même table sachant que la base risque de grossir avec le temps.

Merci a vous

Est-ce qu'il y aura des update ?
Les select sur 5 ans seront-ils courants ?
Les select se feront à quels fréquence ? généralement sur quelles périodes ?

oui assez courant car c'est dans le but de prevoir un planning de maintenance. Quelle periode (je ne comprend pas le sens de la question)

ben j'imagine que tu ne vas pas faire un select à chaque fois sur les 5 ans... non ?

Non en fait les seul fois pour les quel je devrai faire un select sur les 5ans se serra par exemple pour connaitre le tps total de fonctionnement (par exemple)

Quels sont tes cas d'utilisation nominaux ? "assez courant" ne veut rien dire, il faut des chiffres plus précis :) Pour pouvoir faire un choix optimum il faut à mon avis déterminer plus précisément les périodes extraites dans les cas normaux.

Sinon ton problème se rapproche de ce qu'on peut voir dans les systèmes d'information décisionnels/data mining/data warehouse/... Recherche des cours sur ton moteur de recherche préféré là-dessus, tu en ressortiras grandi et tu pourras guider plus facilement tes choix sur une voie "professionnelle"...

le but du programme c'est de pouvoir effectuer une recherche des données de fonctionnement et en dresser un graphique statistique.
Ex j'aimerai avoir le nbr d'heures de fonctionnement du moteur n°234, durant le mois de decembre 2005.
J'aimerai que toutes ces données s'affichent dans un graphique en x les jours en y le tps de fonctionnement.
(on doit pouvoir afficher ces donnees par jour par mois ou par annee)

tout ca dans le but 1 de prevoir un plannig de maintenance 2faire une gestion sur les consomations

qu'est ce qui sera le plus fréquent :
- requete par moteur
- requete sur l'ensemble de tout les moteurs
- ...

C'est vraiment important de ne pas négliger ces petites questions et les autres sous-jacentes car ce sont elles qui vont te permettre de répondre à celle que tu pose au début : dois-je dédier une table par moteur ou bien dois-je tout mettre dans la même table. Si tu ne fais qu'interroger moteur par moteur et que tu veux une vue d'ensemble de ton parc seulement de temps en temps alors il faudra prévilégier (à priori) une table par moteur.

Il faut que tu détermines tout les cas de figure, et préciser à chaque fois la fréquence (1 fois par semaine par 2 chefs... tout les matins par 360 techniciens... etc etc)

les requetes les plus frequentes sont moteur par moteur et la plus part du tps c'est moi qui effectue les requetes( donc 1 personne a la fois)

Bonjour,

Qd tu dis 1 seule table je suppose que tu veux dire que tu mets ttes les mesures ds 1 table (moteur, heure, etat)? Mais que tu as 1 table Heure (date) et 1 table Moteur (moteur, batiment)?
Ds ce cas moi je laisserais tt ds 1 seule table.
1 table par moteur, ça va te compliquer la tache pour faire tes interrogations.
Le schéma étant simple et le but surtout orienté interrogation, tu peux aussi envisager 1 modèle en étoile :
Dimension temps (heure)
Dimension moteur (moteur, batiment)
Faits etat (moteur, heure, etat). A vu de nez la table des faits ferait ds les 200 Mo. C'est pas énorme, mais il faudrait qd même voir comment se comporte MySQL ds ce cas.
Les volumes que tu extrais ne semblant pas démesurés, l'idée de Mr N. est interressante aussi. Tu pourrais importer les données de tes requêtes directement ds excel sur forme de cube pour faire tes graphiques.

A +

Salut! ;)

Citation:

---

Envoyé par TheLeadingEdge

1 table par moteur, ça va te compliquer la tache pour faire tes interrogations.

---

Peux-tu justifier / illustrer ce qui te fait dire ça stp ?
Perso, j'aurais plutot cru l'inverse :

Citation:

---

Envoyé par matterazzo

les requetes les plus frequentes sont moteur par moteur

---

1 table par moteur = 600 tables = 600 requêtes différentes par exemple

600 requêtes ?
N'existe-t-il donc pas une méthode permettant d'opérer sur plusieurs tables d'une même base en une seule requête ?

A ma connaissance pas en SQL, chaque table ayant 1 nom différent il faudra faire 1 rq
SELECT * FROM tablemoteurnumero1 WHERE .... pour interroger la table tablemoteurnumero1, et faire 1 rq
SELECT * FROM tablemoteurnumero2 WHERE .... pour interroger la table tablemoteurnumero2 etc ... et pareil pour les insert.
C'est pas irréalisable, mais ça ne va pas ds le sens de la simplicité.
Et puis et puis il va falloir 1 sacré mémoire pour se rappeler que tablemoteurnumero2 correspond au moteur qui est ds la salle x du batiment y.

Citation:

---

Envoyé par matterazzo

Non en fait les seul fois pour les quel je devrai faire un select sur les 5ans se serra par exemple pour connaitre le tps total de fonctionnement (par exemple)

---

Il veut connaître le temps de fonctionnement total de chaque moteur d'après ce que j'ai compris, pas de la totalité (à confirmer).

Citation:

---

Envoyé par TheLeadingEdge

Et puis et puis il va falloir 1 sacré mémoire pour se rappeler que tablemoteurnumero2 correspond au moteur qui est ds la salle x du batiment y.

---

Je suppose que ces infos seront stockées dans une table... :D

Citation:

---

Envoyé par Sub0

Citation:

---

Envoyé par matterazzo

Non en fait les seul fois pour les quel je devrai faire un select sur les 5ans se serra par exemple pour connaitre le tps total de fonctionnement (par exemple)

---

Il veut connaître le temps de fonctionnement total de chaque moteur, il suffira d'additionner ces temps pour connaître le temps total de tous les moteurs.

---

Dans ce cas, si vraiment il fallait diminuer la taille de la table, je priviligierais plutôt l'éclatement par années.

Citation:

---

Envoyé par Sub0

Citation:

---

Envoyé par TheLeadingEdge

Et puis et puis il va falloir 1 sacré mémoire pour se rappeler que tablemoteurnumero2 correspond au moteur qui est ds la salle x du batiment y.

---

Je suppose que ces infos seront stockées dans une table... :D

---

Oui, mais tjours pareil, avec 1 seule table la jointure est simple, mais pas avec 600.

[ca tourne au chat cette affaire ;-) ]
A cette heure là il n'y a plus grand monde, je pense que ça vaut le coup d'attendre demain pour avoir d'autres opinions (eclairées ?) sur le sujet

Citation:

---

Envoyé par TheLeadingEdge

je priviligierais plutôt l'éclatement par années.

---

+1
C'est pourquoi je posais tant de questions sur les periodes "requètées"...
Ce que je vois, sans connaitre plus en détail les scénarii d'utilisation, c'est une table par moteur pour la période en cours, puis au bout d'un certain temps on passe les vieilles données dans une seule grosse table... Mais bon c'est plus de la prémonition/sciences occultes qu'autre chose sans être dedans...
Au risque de me répeter je pense qu'il faut jeter un oeil sur ce qui se fait dans les systèmes d'information décisionnels.

En fait moi sans avoir posé la question dans se forum, voila comment j'aurai prosede

1 table Batiment :
Num_bat : Numero auto
Nom_bat : Nom du bat
Tel_bat : Num teleph
......

1 table moteur :Num_mot : Numero du moteur
Lib_mot : denomination du moteur
Sit_mot : Endroit ou se situe le moteur (fait ref a num bat)
.........

1 table etat :
Num_etat : (aurait fait ref au num moteur)
[i]Date_etat : date au format DDMMYYYY HHMMSS
Stat_etat : Etat du moteur (M (marche), A (arrete), I (incertain)





Voila se que j'aurai fait, lors d'une requete exemple :

J'aimerai voir le(s) moteur(s) qui se trouve(nt) dans un batiment n°x
[i]

Code:

---

[i]Select * from 'moteur' where batiment.num = ...... ;[/i]

---

J'aimerai connaitre combien de tps a fonctionne le(s) moteur(s) du bat n°y
.........

Voila se que moi j'aurai fait (avec le peut de connaissance que j'ai) je trouve qu'on avait facilement facile d'acces nombre de requete limité
j'aimerai avoir votre avis sur ma structure la base de données Pour et contre .....
Merci a vous

Salut! ;)

Si tu enregistres les dates des changements d'état et que tu veux connaître le temps de fonctionnement, tu seras obligés de faire la soustraction des dates. Il faut donc prendre en compte que tu devras faire un traitement après la requête... Tu peux éventuellement prévoir une ou deux colonnes suplémentaires pour stocker le temps de fonctionnement & d'arrêt en cours, puisqu'il n'y aura que des inserts, pas d'updates dans la table des enregistrements d'états. Ainsi, tu calcules la différence juste avant d'insérer l'enregistrement, en reprenant le dernier temps de fonctionnement enregistré.

http://www.ziguras.com/ref/web/mysql/MySQL%20Manual%20%206_3_4%20Date%20and%20Time%20Functions.htm

Il est possible de chronomètrer le temps mis par une requête pour comparer la rapidité de différentes structures de base de données.

J'ai une question :
Le plus souvent, tu voudras connaître le temps de fonctionnement total d'un moteur ou de la totalité (l'ensemble des 600 moteurs) ?

Le plus souvent je devrait avoir le detail de fonctionnement moteur par moteur(Marche arret incertain) aussi bien sur une journee que sur un mois complet et parfois sur 1an ou plus
exemple savoir combien de temps le moteur n°x a fonctionné jour par jour durant le mois y.

Assez souvent aussi je devrait connaitre le tps de fonctionnement des moteurs d'une region -> exemple j'aimerai savoir le tps de fonctionnement total de tous les moteurs qui se situent a charleroi

Maintenant connaitre le tps de fonctionnement total de tous les moteur on en a aucune utilitée(pour le moment c'est pas dans le cahier des charges)

Voila maintenant j'aimerai avoir votre avis sur la structure a adopter pour la structure de mes tables pour que la vitesse de selection soit la plus rapide possible pcq les données recoltees serviront a realiser un graphique dinamique (il faut pas qu'apres 1an d'enregistrement je doive rester 15min devant mon pc avant que les donnees s'affichent lol )

Citation:

---

Envoyé par matterazzo

il faut pas qu'apres 1an d'enregistrement je doive rester 15min devant mon pc avant que les donnees s'affichent lol

---

c'est pour ça que je te conseille d'ajouter quelques colonnes pour sauver le temps de fonctionnement en cours. Tes graphiques se serviront des ces valeurs au lieu de tout recalculer du début à chaque fois. Qu'en pensent les autres membres ?

Un papiers poussé mais très intéressant sur la gestion du temps sous SQL =>
http://sqlpro.developpez.com/cours/gestiontemps/

Je pense que comme l'a dit Sub0, des colonnes supplémentaires pour le temps cumulé de fonctionnement ne serait à priori pas superflues.

Par contre porte une plus grande attention sur le nom de tes colonnes : tu as nommé sit_mot une colonne qui référence un batiment... Il faut rester cohérent car quelqu'un externe comme moi cherche la table Site. Sinon pour le nommage des colonnes =>
http://sqlpro.developpez.com/cours/standards/#L3.8