En arrivant sur un projet décisionnel, une stratégie d’update avec la fonction binary_checksum avait été appliquée pour détecter les changements. En faisant quelques tests et quelques recherches sur internet, nous nous sommes vite rendus compte que cette fonction ne remplissait pas forcement son rôle. Nous avions des colonnes qui ne se mettaient pas à jour. Voici ce qu’on peut glaner sur Internet :

• un exemple pour comprendre comment fonctionne le binary_checksum

• un article sur msdn qui confirme que cette méthode n’est pas fiable à tous les coups :

« BINARY_CHECKSUM(*), calculé à partir de n’importe quelle ligne d’une table, retourne la même valeur tant que la ligne ne subit aucune modification. BINARY_CHECKSUM(*) retourne une valeur différente pour la plupart des modifications apportées à la ligne (mais pas pour toutes) et permet de détecter la plupart des modifications. »

• un article sur un blog qui résume bien la situation : qu’il ne faut pas utiliser binary_checksum mais plutôt la fonction hashbytes (fonction moins performante que le binary_checksum et plus lourde à mettre en place)

• vous trouverez dans cet article un exemple d’utilisation du hashbytes qui confirme que l’utilisation n’a pas l’air très simple pour arriver à un résultat qui fonctionne à tous les coups

Conclusion nous avons enlevé l’utilisation du binary_checksum pour passer à un update classique basé sur :

• une date de mise à jour
• et sur l’ID unique que l’application nous fournissait

Les performances restent correctes.

Si vous avez eu une expérience binary_checksum ou encore hashbytes n’hésitez pas à la partager avec nous!