Prüfsumme bei der Zusammenführung verwendet?

Wir hatten einen Entwickler, der uns letztes Jahr verlassen hat ... Er war ein großartiger! Als DBA hatte ich viel Spaß ihn im Team zu haben! Aber ich auf dieses Stück Code von ihm kam:Prüfsumme bei der Zusammenführung verwendet?

when matched and 
        checksum(TARGET.Lead_ID, TARGET.Salesforce_id)   <> checksum(SOURCE.Lead_ID,SOURCE.Salesforce_id) 
      or  checksum(TARGET.Lead_ID, TARGET.CreatedById)   <> checksum(SOURCE.Lead_ID,SOURCE.CreatedById) 
      or  checksum(TARGET.Lead_ID, TARGET.Email)     <> checksum(SOURCE.Lead_ID,SOURCE.Email) 
      or  checksum(TARGET.Lead_ID, TARGET.LastModifiedById)  <> checksum(SOURCE.Lead_ID,SOURCE.LastModifiedById)   
      or  checksum(TARGET.Lead_ID, TARGET.ConvertedContactId)  <> checksum(SOURCE.Lead_ID,SOURCE.ConvertedContactId) 
      or  checksum(TARGET.Lead_ID, TARGET.ConvertedDate)   <> checksum(SOURCE.Lead_ID,SOURCE.ConvertedDate) 
      or  checksum(TARGET.Lead_ID, TARGET.ConvertedOpportunityId) <> checksum(SOURCE.Lead_ID,SOURCE.ConvertedOpportunityId) 
      or  TARGET.IsConverted          <> SOURCE.IsConverted   
      or  checksum(TARGET.Lead_ID, TARGET.Mini_West_Local_Marketing__c) <> checksum(SOURCE.Lead_ID,SOURCE.Mini_West_Local_Marketing__c) 
      or  checksum(TARGET.Lead_ID, TARGET.Valid_Leads__c)   <> checksum(SOURCE.Lead_ID,SOURCE.Valid_Leads__c) 
      or  checksum(TARGET.Lead_ID, TARGET.FE_Owner__c)   <> checksum(SOURCE.Lead_ID,SOURCE.FE_Owner__c) 
      or  checksum(TARGET.Lead_ID, TARGET.FE_Sales_Group__c)   <> checksum(SOURCE.Lead_ID,SOURCE.FE_Sales_Group__c)

Ich weiß Prüfsumme: „gibt die Prüfsumme Wert über eine Zeile einer Tabelle berechnet wird, oder über eine Liste von Ausdrücken. CHECKSUM dient zur Erstellung von Hash-Indizes. "

Aber warum sollte er es dort benutzen?

Anmerkung: (Dies ist ein Teil des Codes, die wirklichen ‚wenn angepasst‘ -Klausel 100 Spalten hatte, sowohl Quelle als auch Ziel haben 100 Spalten ...)

Quelle

2016-10-28 Chicago1988

Meine beste Vermutung ist, er versucht zu „schnell“ erkennen Änderungen bei gleichzeitiger Vermeidung von NULL Semantik zur gleichen Zeit.

nicht ganz sicher, warum er es so schreiben würde bei der Verwendung von (EXISTS + EXCEPT) oder (NOT EXISTS + INTERSECT) erscheint die gleichen Ergebnisse ohne N Zweige und N * 2 CHECKSUM Operationen auszuführen:

when matched 
and exists (
     select [SOURCE].[Lead_ID] 
       , [SOURCE].[Salesforce_id] 
       , [SOURCE].[CreatedById] 
       , ... 
     except 
     select [TARGET].[Lead_ID] 
       , [TARGET].[Salesforce_id] 
       , [TARGET].[CreatedById] 
       , ... 
    )

Quelle

2016-10-28 14:13:30 Kittoes0124

Danke Kittoes0124! Ich denke, du hast recht, aber noch mehr ... Die Quelle, die wir für die Zusammenführung verwenden, ist a: "Von SourceTable Where UpdateDate> @LastUpdateDate" ... Also gibt es keine Notwendigkeit, eine Überprüfung durchzuführen: Wenn ein Datensatz gezogen und angepasst wurde, es ist, weil es in der Quelle aktualisiert wurde ... Ich werde es in ein "wenn passed dann UPDATE" ändern ... Jedes mögliche Problem/Warnung, die ich vermisse? Ich werde völlig darauf vertrauen, dass UpdateDate korrekt an der Quelle verwendet wird. – Chicago1988

@ Chicago1988 Wenn Sie sicher wissen, dass es keine Notwendigkeit, die Prüfung durchzuführen, dann nicht tun. Es hat keinen Sinn CPU-Zyklen zu verschwenden, wenn Sie sie bereits in einem früheren Teil des Prozesses ausgegeben haben. Ich verwende das 'exists' /' except' Muster nur in Situationen, in denen ich nicht weiß, ob die eingehenden Werte verschieden sind oder nicht ** und ** Ich möchte vermeiden, dass unveränderte Spalten aus irgendeinem Grund mutiert werden (Audit, Größe). – Kittoes0124

Prüfsumme bei der Zusammenführung verwendet?

Antwort

Verwandte Themen