Antwoord.

Sinds de opkomst van gegevensintegratietaken rijst vaak de vraag naar programmatische synchronisatie: we moeten alleen de daadwerkelijk gewijzigde rijen bijwerken om middelen te besparen en het blokkeren te minimaliseren. De standaardaanpak in het verleden bestond uit volledige vervanging of handmatige vergelijking van verschillen, wat leidde tot onnodige bewerkingen en fouten.

Probleem: bij synchronisatie moet men alleen de gewijzigde gegevens ontdekken en bijwerken, en niet alles. Dit is belangrijk voor de prestaties, netwerkverkeer en integriteit, vooral bij grote hoeveelheden of gedistribueerde databases.

Oplossing: meestal wordt de vergelijking tussen de bron- en doeltabellen uitgevoerd met behulp van JOIN-operatoren, worden verschillen berekend via HASH of check-som, en worden alleen de "verschillende" rijen bijgewerkt met behulp van MERGE (of UPSERT) of speciale triggers.

Voorbeeldcode (in 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);

Belangrijke kenmerken:

Gebruik van MERGE/UPSERT zonder herhaalde updates van ongewijzigde rijen
Mogelijkheid om niet alleen op PK, maar ook op andere unieke velden te matchen
Controle alleen op daadwerkelijk gewijzigde kolomwaarden (via voorwaarden)

Vragen met een valstrik.

Geeft MERGE altijd de afwezigheid van race-omstandigheden bij gelijktijdige updates?

Nee, zonder extra controle van transacties kunnen race-omstandigheden optreden. Gebruik voor maximale correctheid het juiste isolatieniveau van transacties.

Kan ik UPDATE ... JOIN gebruiken in plaats van MERGE voor complexe synchronisatie?

Vaak kan dat, maar deze aanpak staat niet toe om nieuwe rijen aan de doeltabel toe te voegen. Alleen MERGE/UPSERT kan bijwerken en toevoegen.

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;

Wat te doen als de te synchroniseren tabellen niet-overeenkomende kolomniveaus hebben?

Het wordt aanbevolen om de te koppelen velden expliciet op te sommen en niet te proberen "altijd alles" bij te werken. Gebruik indien nodig mapping-tabellen of conversies.

Typische fouten en antipatterns

Het bijwerken van alle rijen zonder uitzondering (zelfs ongewijzigde)
Geen controle op de aanwezigheid van nieuwe rijen (invoegingen)
Geen controle van transacties, wat leidt tot dubbele updates

Voorbeeld uit het leven

Negatieve case

Een ETL-engineer "laadt" gegevens met behulp van een eenvoudige UPDATE van alle records op sleutel: de tabel met tientallen miljoenen rijen, het proces duurt uren en blokkeert de server. Er is geen aparte invoeging van nieuwe rijen, waardoor nieuwe gegevens verloren gaan.

Voordelen:

Eenvoudige code

Nadelen:

Langzaam, bespaart geen middelen, risico op verlies van nieuwe gegevens

Positieve case

Een specialist berekent vóór de invoer de controle sommen van de rijen, filtert de gewijzigde records, gebruikt MERGE voor snelle synchronisatie en toevoegt nieuwe rijen. Het proces duurt enkele minuten zonder overbelasting.