Discussion :

[vasilov]

Bonjour à tous,

j'aimerai votre avis pour savoir si mes tables sont optimisées.

Je récupère les valeurs d'une 50aine de capteurs toutes les heures et les stoques dans les tables suivantes :

La table capteurs qui stocke les noms et caractéristiques des différents capteurs :

id (int) unique, autoincremental
nom (varchar 255)
caractéristiques (varchar 255)

clée unique : l'id


La table capteurValues qui stocke les valeurs des capteurs aux différents instants :

capteur_id (int)
value (double)
timestamp (timestamp)

comme clée unique : le couple (capteur_id, timestamp)
et un autre index : timestamp (pour accélérer les select)

Mon problème est qu'il y a environ 1250 valeurs supplémentaires dans la table capteurValues tous les jours. J'ai peur qu'un select dans cette table devienne long.
Ils sont du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT `value` , `timestamp` FROM `capteurValues` 
     WHERE `value_id` = '" . $id . "' 
          AND `timestamp` > '" . $lastMonth . "' 
     ORDER BY `timestamp` ASC

Pensez vous que ce soit un risque ?
Pensez vous que sauvegarder les vieilles valeurs dans une tables poubelle soit une bonne idée (et du coup les supprimer de la table capteurValues)

Merci beaucoup pour votre éclairage

[ABCIWEB]

Mon problème est qu'il y a environ 1250 valeurs supplémentaires dans la table capteurValues tous les jours.
Pensez vous que ce soit un risque ?
Pensez vous que sauvegarder les vieilles valeurs dans une tables poubelle soit une bonne idée (et du coup les supprimer de la table capteurValues)

Merci beaucoup pour votre éclairage

Le plus simple pour avoir la réponse est encore de faire des tests de montée en charge. En fonction de cela tu pourras savoir quand il te faudra créer tes tables d'archive.

[RunCodePhp]

Salut

Avoir une idée de la quantité de données qui commencerait à devenir problématique serait nécessaire.

L'idée de tables "archives" peut être envisagé.
Ca me rappel en vieux TP que j'avais lu, dont l'idée était intéressante aussi.
L'idée était de créer non pas plusieurs tables, mais des Bdd "archives".

A la base, il y a une Bdd "maitre" qui elle gère d'autres Bdd "esclaves".
Donc cette Bdd "maitre" (très basique) stock essentiellement les infos des Bdd "esclaves" comme : leurs nom, leur fonction (production, archive), leur statut (en service/hors service).
On peu faire ce qu'on veut en faite.
Et l'autre idée était de faire une Bdd par année, mais on peu faire 1/mois, peu importe.

Ceci dit, il est claire que ce n'est pas si simple, faut prévoir le coup, mais si toutes les Bdd ont la même structure (même tables, même noms, même champ et même nom de champs), ça peu se faire sans trop de mal.

Faut prévoir tout de même la création automatique des nouvelles Bdd.
De même leur destruction au bout d'un certain délai (au-delà de 2, 3 ans par exemple).

La difficulté principale, et pas des moindre, c'est si le projet évolue, les tables changent (nouveau champ, suppression de champ, les noms changent, etc ...), ça peut être compliqué de faire un suivi dans le temps.


Mais c'est juste une idée.