Discussion :

[123456789az]

Bonjour,

J'ai une table toute simple nommée "Histo" à 2 colonnes (date et valeur) dans laquelle arrive des données de différents équipements de mesures (Ce n'est pas moi qui ai développé cette partie mais elle fonctionne). Le soucis est que l'un des équipements envoi "16535" au lieu des "0".
J'ai une requête toute simple pour remplacer ces valeurs par des 0, mais le soucis est que j'aimerais bien l'automatiser :
- Soit à chaque fois qu'une valeur est > à 1000 par exemple, mais ça veut dire qu'il faut scruter en permanence les données (Pas top)
- Soit à intervalle de temps régulier, toutes les semaines par exemple.

Est-il possible d'écrire cette requête en dur et de la lancer toutes les semaines à minuit par exemple ? Si oui, comment faire ??


Merci beaucoup,

[elsuket]

Bonjour,

Dans le premier cas, dans la requête INSERT, le SELECT peut avoir l'expression suivante :

Code :

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

SELECT CASE WHEN valeur > 10000 THEN 0 ELSE valeur END AS valeur

Dans le deuxième cas, le code du job de l'Agent SQL Server, planifié pour s'exécuter toutes les nuits par exemple, sera certainement un UPDATE, comme celui qui suit :

Code :

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

1
2
3
4
UPDATE	dbo.Histo
SET	valeur = 0
WHERE	date BETWEEN DATEADD(day, -1, CAST(SYSDATETIME() AS date)) AND CAST(SYSDATETIME() AS date)
AND	valeur > 10000

Attention à avoir un index sur {date,valeur}
En outre, si le nom de la colonne est réellement date, il faudrait le changer puisque c'est un mot clé désignant le type de données du même nom.

@++

[123456789az]

Dans mon cas c'est plutôt un UPDATE que je fais actuellement, et j'ai évidemment une colonne id

Code :

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

1
2
3
UPDATE dbo.histo
SET valeur = 0 
WHERE id = 6000 and value > 10000

Ou dois-je déclarer cette requête ? Dans les procédures stockées ? Et ensuite je lance cette procédure tous les X heures avec l'agent SQL ?

[elsuket]

j'ai évidemment une colonne id

Ce n'est pas tout à fait pareil que :

J'ai une table toute simple nommée "Histo" à 2 colonnes (date et valeur)

Si la colonne id est supportée par une clé primaire, je ne suis pas sûr de comprendre le WHERE de l'UPDATE que vous venez de donner :

Code :

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

WHERE id = 6000 and value > 10000

Le mieux me semble être de corriger les données en amont, c'est à dire avant qu'elles ne soient stockées dans la base de données.
Ensuite, tout dépend de la quantité de lignes que la table reçoit par seconde, par exemple.
Si c'est relativement faible, un job toutes les heures peut tout à fait convenir; il faudra simplement adapter la clause WHERE pour qu'elle spécifie l'heure précédente.
Si ce sont des millions de lignes, probablement que l'exécution du job une fois par jour, la nuit par exemple s'il y a moins de lignes insérées, et un traitement par lots de lignes, serait plus adaptée.

Vous pouvez effectivement exécuter cette requête en appelant une procédure stockée, ou en collant le texte de la requête dans la commande de l'étape du job, à la place de l'appel de la procédure stockée.
Je trouve la seconde approche moins propre, même si elle est un tout petit peu plus "transportable" : il suffit de scripter le job pour le porter sur une autre instance SQL Server.
Il vous reste donc la planification du job, que vous pouvez tout à fait spécifier à une fois toutes les heures, ou toutes les 3h, ou une fois par jour, ou tous les 2e mardis du mois, ...

Néanmoins si ce qui vous intéresse est simplement de corriger ce que l'on peut considérer comme la présentation des données, mais pas les valeurs telles qu'elles sont arrivées dans la table, alors il vaut mieux vous orienter vers une vue.
Une vue est définie par une requête SELECT, dans laquelle vous pouvez tout à fait spécifier le premier SELECT que je vous ai proposé. Elle s'interroge comme une table.
La différence, c'est qu'alors vous n'interrogez que la vue, et qu'il n'y a plus de maintenance des données à effectuer.
Cette approche est notamment intéressante si vous devez investiguer un jour l'ingestion par la base de données de valeurs farfelues ...

Donc pour vous aider, il faudrait que vous distilliez un peu plus de votre contexte

@++

[123456789az]

Bonjour,

Merci pour votre réponse, je vais essayer d'être un peu plus clair.

Pour la clé primaire, elle se trouve sur les colonnes 'Id' et 'Date'.
En amont de cette base, des équipements qui viennent rentrer leurs données. En aval, on a un superviseur qui vient lire ces données.

Là encore tout est déjà développé donc la vue ne semble pas convenir puisque le superviseur vient "taper" dans cette table pour afficher les données nécessaires. Mon objectif est juste de remplacer certaines valeurs qui sont fausses (C'est l'équipement en amont qui envoi ces valeurs farfelues).

Pour ce qui est de corriger ces données en amont, j'aimerais éviter de toucher à tout ce qui a été développé par mon ancien collègue au niveau des procédures d'insertion des données. La table reçoit 1ligne/10min donc il y a une quantité assez faible de données. Il suffirait "juste" de lancer la procédure UPDATE que j'ai citée 1 à 2 fois par jour, cela suffirait car les données ne sont pas consultées en permanence

[elsuket]

OK, donc effectivement dans ce cas il faudra s'en remettre à une exécution de la procédure stockée par un job de l'Agent SQL Server.

@++