Discussion :

[Yellow-Sky]

Bonjour,
je suis plutôt débutant dans la gestion des bases de données.
Ma question pourra donc paraitre simple mais je n'ai pas trouvé de réponses satisfaisantes.

Je dois constituer une base de données avec des mesures de capteurs (température, vitesse...). Chaque capteur est enregistrer au moins 1* par 5 minutes => ~100 000 enregistrements /an / capteur. On peut compter qu'à termes il y aura plusieurs dizaines de capteur => plusieurs millions d'entrées par an

Pour le moment j'ai réalisé une table dont la structure est la suivante:
ID (identifiant avec auto increment)
Datetime (le moment de l'enregistrement)
Valeur (La valeur, ce sont tous des nombres avec une seule décimale et toujours inférieure à 100)
Capteur (un identifiant unique incorporant le capteur)

Je voulais savoir si la logique était la bonne ou s'il était préférable de créer une table par capteur pour améliorer les performances de recherches ultérieures. Ou toute autre alternative qui vous semble mieux convenir à ce cas de figure

Merci pour votre aide.

[escartefigue]

bonjour

Si les caractéristiques des capteurs sont intéressantes, il faut une table des capteurs et une table des mesures, sinon vous êtes contraints de répéter les caractéristiques d'un même capteur autant de fois qu'il fait une mesure. Or, c'est exactement ce qu'il ne faut pas faire.
Si au contraire les caractéristiques des capteurs sont sans intérêt, pourquoi stocker un identifiant du capteur, est-ce une donnée qui vous est communiquée par un tiers ?

Voici un autre sujet qui concerne les capteurs et mesures et qui pourra peut être vous aider :
https://www.developpez.net/forums/d1...ions-capteurs/

[Yellow-Sky]

L'identifiant unique du capteur sert d'une part à faire une recherche sur le capteur mais également à utiliser une autre table avec les caractéristiques des capteurs pour éviter de les enregistrer à chaque fois.
La question que je me pose c'est qu'après plusieurs mois/années, la table va contenir plusieurs millions d'enregistrements et je me demande si c'est opportun de n'avoir qu'une seule table... car les recherches me semblent (mais je me trompe peut-être) plus longue à réaliser.

[escartefigue]

Une seule table est préférable, mais il faut prévoir un archivage voire une suppression des données obsolètes et utiliser le partitionnement si le volume devient très conséquent (des dizaines de millions de lignes et +)

Ne créez surtout pas une table par capteur : si vous voulez analyser par exemple toutes les mesures du mois tous capteurs confondus, il faudra faire autant de jointures qu'il y a de capteurs très mauvaise idée
Autre exemple : vous voulez rechercher tous les capteurs achetés il y a plus de 10 ans pour planifier leur remplacement, là aussi vous allez faire une jointure (ou union ou autant de requêtes) qu'il y a de capteurs ? Pas bien non plus

Consulter une table de plusieurs centaines de millions de lignes ne pose aucun problème de performances si la requête est bien construite et qu'il existe des index filtrants

[Yellow-Sky]

Je comprends le problème de tables séparées si des jointures (ou assimilé) étaient nécessaires (même si je dois avouer que je ne planifie absolument pas ce type de requête).
Si vous me dites que plusieurs millions d'enregistrements ne posent pas problème, alors je pense conserver ma solution... qui semble convenir

Quand vous parlez de requête bien construite... Dans mon cas le but est de faire un select sur un capteur dans une plage de date, est-ce cohérent? A mon sens ce sont les index filtrants mais ne connaissant pas la terminologie je préfère m'en assurer

Encore merci.

[escartefigue]

Filtrant signifie que le nombre de lignes récupérées par la requête au moyen de l'index est une proportion très faible de la population totale de la table.

Si les requêtes ne doivent concerner qu'un seul capteur pour une plage de dates et qu'il y a un grand nombre de capteurs alors il faudra créer un index ayant pour 1^re colonne le n° de capteur puis la date de la mesure.

Si les requêtes concernent tous les capteurs pour une période, ou qu'il y a très peu de capteurs, alors il faut un index sur la date de mesure seule

[Yellow-Sky]

Naïvement, je pensais que lorsque je faisais une recherche sur une colonne je filtrai mais apparemment pas au moyen d'un index...

Auriez vous :
- un conseil à me donner dans la gestion des index au vu de la table présentée et des recherches que je compte faire: sélection d'un ou plusieurs capteurs durant une période donnée pour afficher les données sur un graphique?
- une référence pouvant aider le néophyte que je suis dans le gestion d'index et l'optimisation de cette table

Je vous remercie.

[escartefigue]

Naïvement, je pensais que lorsque je faisais une recherche sur une colonne je filtrai mais apparemment pas au moyen d'un index...

Ca dépend : c'est le cas si au moins un index existe pour les critères de filtrage et que ces critères sont dits "sargable" (Search Argument Able)
Sont "sargable" les critères utilisés avec des opérateurs tels que =, <, >, between...
Ne sont pas "sargable" les critères utilisés avec des opérateurs tels que like '%xxx%', !=, les critères dont le type ou la taille sont différents de ceux de la colonne recherchée, les fonctions appliquées sur la colonne...

Les index sont des éléments du modèle physique de données, ils sont donc liés au choix du SGBD.
Les conseils donnés plus haut sont valables quel que soit le SGBD, mais pas les modalités de mise en oeuvre.

Pour des réponses détaillées, il faut donc se rendre dans le forum consacré aux différents SGBD dont la racine se trouve ici :
https://www.developpez.net/forums/f4/bases-donnees/

[Yellow-Sky]

Merci pour les détails.
En l’occurrence un champs int et Datetime seraient sargables donc cela semble bon.
Je clôture et vais suivre votre conseil.

[escartefigue]

En l’occurrence un champs int et Datetime seraient sargables donc cela semble bon.

Attention :

Soit, par exemple une colonne TAB1.COL1 de type integer

Les prédicats suivants sont "sargable" :
where TAB1.COL1 = 10.
where TAB1.COL1 > 15.
where TAB1.COL1 between 22 and 30.

Mais ces prédicats ne le sont pas
where decimal(TAB1.COL1) = 10 <-- utilisation d'une fonction sur la colonne : aucun index éligible.
where TAB1.COL1 != 10 <-- opérateur "différent de" non sargable

Le type de la colonne seul ne suffit pas à vérifier si le prédicat est sargable

[Yellow-Sky]

Merci pour les précisions.