Discussion :

[olibara]

Bonjour


J'ai une table qui doit enregistrer des relevés de compteur : Maximum une valeur par date (jour)
Mais l’opérateur peut se tromper et faire plusieurs relevé a la même date.
Seul le dernier doit être enregistré
Par contre les mesures consécutives a la même date devrait être enregistrée dans une table de Log

Je voudrais donc définir un Trigger pour contrôler cela mais avant d'inventer n'importe quoi je me demande s'il existe une manière recommandée pour ce type d'opération

Voici la table principale, la table de log s'appelle IndexHistoryLog et a le même design

Merci pour votre aide

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE [dbo].[IndexHistory](
	[pkId] [int] IDENTITY(1,1) NOT NULL,
	[CounterId] [int] NOT NULL,
	[IndexValue] [decimal](18, 4) NOT NULL,
	[Date] [datetime] NOT NULL,
	[OperatorId] [int] NULL,
	[pictureUrl] [varchar](200) NULL,
	[Remark] [varchar](200) NULL,
	[isDisabled] [bit] NULL,
PRIMARY KEY CLUSTERED 
(
	[pkId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

[StringBuilder]

Si la table de "log" a la même structure, alors tu prends le problème à l'envers.

Ne conserve que cette table, et crée une vue dessus pour ramener, pour chaque jour, la première mesure de chaque compteur.

Ceci évitera de passer par un trigger inutile et de dupliquer des données, etc.

[olibara]

Merci Stringbuilder

Oui je connais cette solution mais elle ne me séduit pas vraiment dans ce contexte
Je pourrais faire une vue sur base d'un over partition qui ne rendrait que la dernière mesure par jour

MAIS :
1- Il n'est pas certain que ma table Log aura exactement la même structure
2- La vue aura un impact négatif sur la performance
3- Conceptuellement et pratiquement je préfère pouvoir accéder une table "Propre" ne contenant que l'information pertinente en "prod", la table log n'etant utile que dans un cadre d'audit
4- Donc Mon "à l'Envers" et ton, "a l'Endroit" ne sont que deux manières de voir les choses tout a fait réversibles

Et pour ma part je suis toujours intéressé a voir la manière la plus élégante de résoudre mon idée via un trigger

[StringBuilder]

Une vue devrait avoir un impact pour ainsi dire transparent sur les performances.

A mon avis, c'est pas un élément à prendre en considération, d'autant qu'à l'inverse, un trigger aura, lui, de facto un impacte significativement négatif sur les performances.

D'un point de vue conception, dupliquer des données est une erreur.
Cela se solde par une possibilité d'avoir des données incohérentes : si un trigger va aisément permettre de modifier les données du log, comment gérer les modifications dans la table de log ?

Une vue pouvant être mise à jour (par l'apposition de triggers simples si nécessaires) il est tout à fait possible de travailler "simplement" en PROD sur la vue sans se soucier du log.

Une solution à base de triggers qui vont faires des insert, update, delete, puis recopie dans une autre table, ça sera forcément "sale" car le nombre de cas est important, et vouloir trop simplifier risque de poser problème : que faire si le technicien saisit une donnée, puis une seconde, puis décide de supprimer la ligne ? Doit-on conserver le log ? Doit-on remettre la première donnée ?
=> Il faut stocker les données simplement, et proposer une IHM permettant de choisir l'action à effectuer.

Enfin, à partir de SQL Server 2016, il existe des tables "temporelles" : de telles tables historisent les modifications de données automatiquement :
- https://docs.microsoft.com/en-us/sql...emporal-tables
- https://www.sqlshack.com/track-histo...mporal-tables/
=> Si la solution de la vue n'est pas celle que vous retenez, étudiez au moins celle-là. Attention cependant, elle ne couvrira pas forcément vos besoin en cas de suppression de données...

[olibara]

Merci StringBuilder

Mais je ne suis pas vraiment convaincu du non-impact de performance par l'usage d'une vue
J'avais fait cela pour avoir le dernier prix des items d'un catalogue dont les tarifs évoluaient très souvent

Au bout de deux ans et quelques millions d'entrées ça devenait de plus en plus poussif !
Et j'avais passé pas mal de temps a optimiser les index, le ove partition etc !

J'ai donc basculé en double table avec un Trigger et tout le monde est redevenu heureux

Mais le cas était un peu plus simple car je ne conservait que le dernier update dans la table de reference et TOUTES les modification etaient logué avec un code CRUD dans la table historique
Ici c'est plus subtil car je ne veux loguer QUE les modifications portant sur une meme date
Donc on ajoute un index a une date donnée : pas de log
On Ajoute (insert) ou on modifie (update) ce même index pour la même date : on fait un Update et on logue l'info
La question du delete ne se pose pas : il n'y en a pas
Pour info les opération se font via une application mobile avec un nombre d'opérations limitées.

Donc ma question ne porte pas vraiment sur la pertinence de mettre un Trigger (mon expérience m'a déja démontré l'efficacité de la solution) mais sur la bonne manière ou les erreurs a eviter ppour ce trigger qui doit prendre quelques décisions logique.. Mais son impact sera limité car la frequence des requetes est asser faible

[François DORIN]

Bonjour,

Si la vue a un impact, alors peut-être serait-il bon de tester une vue indexée ! D'autant plus que les accès en écriture sont relativement faibles.

Tu évites ainsi :

• la duplication des données (bon, elles seront dupliquées physiquement, mais c'est SQL Server qui gère cela, pas toi !)
• une vue couteuse

Bonus : tu peux créer des index sur ta vue...