Pourquoi ne souhaitez-vous pas utiliser de déclencheurs ? Ils sont une bonne chose si vous les utilisez correctement. Si vous les utilisez comme un moyen d'appliquer l'intégrité référentielle, c'est à ce moment-là qu'ils passent du bon au mauvais. Mais si vous les utilisez pour la surveillance, ils ne sont pas vraiment considérés comme tabous.

À quelle fréquence devez-vous vérifier les modifications et quelle est la taille (en termes de taille de ligne) des tables dans la base de données ? Si vous utilisez la méthode CHECKSUM_AGG(BINARY_CHECKSUM(*)) suggérée par John, elle analysera chaque ligne de la table spécifiée. L'indice NOLOCK aide, mais sur une grande base de données, vous touchez toujours chaque ligne. Vous devrez également stocker la somme de contrôle pour chaque ligne afin que vous sachiez qu'une a changé.

Avez-vous envisagé d'aborder cette question sous un angle différent ? Si vous ne souhaitez pas modifier le schéma pour ajouter des déclencheurs (ce qui est logique, ce n'est pas votre base de données), avez-vous envisagé de travailler avec le fournisseur de l'application qui crée la base de données ?

Ils pourraient implémenter une API qui fournit un mécanisme pour notifier aux applications accessoires que les données ont changé. Cela pourrait être aussi simple que d'écrire dans une table de notification qui répertorie quelle table et quelle ligne ont été modifiées. Cela pourrait être mis en œuvre via des déclencheurs ou du code d'application. De votre côté, cela n'aurait pas d'importance, votre seule préoccupation serait de scanner périodiquement le tableau des notifications. L'impact sur les performances de la base de données serait bien inférieur à l'analyse de chaque ligne à la recherche de modifications.

Le plus difficile serait de convaincre le fournisseur de l'application d'implémenter cette fonctionnalité. Étant donné que cela peut être entièrement géré via SQL via des déclencheurs, vous pouvez faire le gros du travail pour eux en écrivant et en testant les déclencheurs, puis en apportant le code au fournisseur de l'application. En faisant en sorte que le fournisseur prenne en charge les déclencheurs, cela évite la situation où votre ajout d'un déclencheur remplace par inadvertance un déclencheur fourni par le fournisseur.

Devinette ici : si vous ne souhaitez pas modifier les tables du tiers, pouvez-vous créer une vue, puis mettre un déclencheur sur cette vue ?