Réponse.

Depuis l'apparition des tâches d'intégration des données entre les systèmes, la question de la synchronisation programmée se pose souvent : il faut mettre à jour uniquement les lignes réellement modifiées, économisant des ressources et minimisant les verrous. L'approche standard dans le passé consistait à effectuer un remplacement complet ou une recherche manuelle des différences, ce qui entraînait des opérations superflues et des erreurs.

Problème : lors de la synchronisation, il faut détecter et mettre à jour uniquement les données modifiées, et non toutes indiscriminément. Cela est important pour la performance, le trafic réseau et l'intégrité, surtout avec de grands volumes ou des bases de données réparties.

Solution : on réalise généralement une comparaison entre la table source et la table cible à l'aide d'opérateurs JOIN, calcule les différences via un HASH ou une somme de contrôle, et met à jour uniquement les lignes "disparates" à l'aide de MERGE (ou UPSERT) ou de déclencheurs spéciaux.

Exemple de code (sur SQL Server) :

MERGE target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN MATCHED AND (t.name <> s.name OR t.value <> s.value) THEN
  UPDATE SET t.name = s.name, t.value = s.value
WHEN NOT MATCHED BY TARGET THEN
  INSERT (id, name, value) VALUES (s.id, s.name, s.value);

Caractéristiques clés :

Utilisation de MERGE/UPSERT sans mise à jour répétée des lignes non modifiées
Possibilité de faire correspondre non seulement par PK, mais aussi par d'autres champs uniques
Vérification uniquement des colonnes qui ont réellement modifié leur valeur (via condition)

Questions pièges.

MERGE garantit-il toujours l'absence de conflits lors des mises à jour simultanées ?

Non, sans contrôle supplémentaire des transactions, des conflits (race condition) peuvent survenir. Pour une précision maximale, utilisez le niveau d'isolation des transactions approprié.

Peut-on utiliser UPDATE ... JOIN au lieu de MERGE pour une synchronisation complexe ?

Souvent, oui, mais cette approche ne permettra pas d'ajouter de nouvelles lignes à la table cible. Seul MERGE/UPSERT met à jour et ajoute.

UPDATE t SET t.name = s.name, t.value = s.value
FROM target_table t
JOIN source_table s ON t.id = s.id
WHERE t.name <> s.name OR t.value <> s.value;

Que faire si les tables synchronisées ont des ensembles de colonnes non correspondants ?

Il est recommandé de lister explicitement les champs correspondants et de ne pas essayer de mettre à jour "toujours tous" les champs. Si nécessaire, utilisez des tables de correspondance ou des transformations.

Erreurs typiques et anti-modèles

Mise à jour de toutes les lignes consécutivement (même celles non modifiées)
Absence de vérification pour l'existence de nouvelles lignes (inserts)
Absence de contrôle des transactions, ce qui conduit à des mises à jour doublées.

Exemple de la vie réelle

Cas négatif

L'ingénieur ETL "charge" des données à l'aide d'une simple mise à jour de toutes les enregistrements par clé : la table contient des dizaines de millions de lignes, le processus prend des heures et bloque le serveur. Aucune insertion distincte de nouvelles lignes, les données récentes sont perdues.

Avantages :

Code simple

Inconvénients :

Lent, n'économise pas les ressources, risque de perdre de nouvelles données

Cas positif

Un spécialiste calcule les sommes de contrôle des lignes avant la charge, filtre les enregistrements modifiés, utilise MERGE pour une synchronisation rapide et l'insertion de nouvelles lignes. Le processus se déroule en quelques minutes sans surcharge.