Search

onze sponsors

microsoft_logo.gif


 

computrain_logo.JPG

Forum Login | Register
   Forum

 

Subject: To checksum or not to checksum
Prev Next
You are not authorized to post a reply.

Author Messages
Arjan FraaijUser is Offline

Posts:110

07-11-2008 09:10:30 Alert 

Hallo,

Zoals iedereen natuurlijk weet wordt er in data warehouse modellen regelmatig gebruik gemaakt van zogenaamde delta structuren om het load proces te verlichten.

Een veel gebruikte methoden is gewoon twee tabellen en hun velden tegen elkaar te vergelijken. Bij echter brede tabellen (veel kolommen) die vergeleken moet worden kan dit een redelijk vertragende factor gaan worden.

Ik zie nu dat er dan gebruik gemaakt wordt van CHECKSUM() of BINARY_CHECKSUM(), alleen lees ik ook op het web dat hier wel eens problemen mee kunnen onstaan dat verschillende gegevens dezelfde checksum opleveren, zie onderstaand voorbeeld:

SELECT BINARY_CHECKSUM('aa','AA','Arjan')
-----------
4225134

SELECT BINARY_CHECKSUM('BQ','AA','Arjan')
-----------
4225134

Bovenstaande is gedaan op een SQL2000 server, ik heb even geen SQL2005 bij de hand, geldt hier het zelfde?
De kans hierop verminderd natuurlijk met het aantal velden dat je in je checksum opneemt, maar de kans blijft dus bestaan.

Wat zou je hier aan doen?

Iemand als eens bezig geweest met de checksum task: http://www.sqlis.com/post/Checksum-Transformation.aspx ? Zou die wel uniek zijn in alle gevallen?

Gr,
Arjan

Arjan FraaijUser is Offline

Posts:110

07-11-2008 14:11:51 Alert 
Reactie van Darren Green op de Checksum Task:

Checksums like this that produce a 32-bit integer by their very nature cannot be guaranteed to unique. You only have 4 bytes to store your result in which limits the number of possible values, so collisions are bound to occur. For example using a checksum to differentiate between rows in a large table would be very risky, but using it to detect changes between old and new row values is much more appropriate, but you must still cater for the risk of collisions. The use of the hash for index scenarios is also reasonable, as here the checksum is only used as part of the search criteria to improve the initial search performance.

For a unique hash, use function such as MD5 or one of the cryptographic hash functions. You will however produce a much larger value, probably in excess of 200 bytes, so immediately storage requirements increase, and also search and match performance will decrease. The choice is yours.
Ronald KraijesteijnUser is Offline

Posts:37

11-11-2008 14:34:14 Alert 
Hoi Arjan,

Ik maak hiervoor gebruik van een MD5 hash over een aantal kolommen, zo kan de ETL heel snel zien of een record veranderd is ja of de neen. Als je hulp nodig hebt moet je maar even een berichtje sturen, ik heb eventueel een voorbeeldpackage in SSIS.
grts. Ronald

SQL2k5 tips/trick @ http://www.sqlblog.nl/
Arjan FraaijUser is Offline

Posts:110

12-11-2008 15:48:09 Alert 
@Ronald:

Ronald bedankt voor je reactie, de MD5 algoritme is natuurlijk ook bruikbaar maar vraagt deze niet meer tijd voor het bereken van de checksum en de opslag capaciteit?
Is dit merkbaar / meetbaar?

Ik ontvang natuurlijk graag een voorbeeld package..
You are not authorized to post a reply.
Forums > Forums > Business Intelligence > To checksum or not to checksum



ActiveForums 3.6
  
Copyright (c) 2012 PASS Nederland   Privacy Statement  Terms Of Use