Per l'actualització de la dimensió / fet ha de determinar si hi ha un registre. Això normalment es fa mirant el negoci clau (clau natural) en la dimensió. Si no ho troba, és un registre nou i ha de ser vostè a inserir. Si aquest es troba i s'ha canviat el registre ha de ser actualitzat (tipus 1) o si un nou registre que es crearà (tipus 2). Jo sóc el que la expirementeren estat en el procés de fer una cerca per accelerar. Aquí els meus resultats fins ara.
Feu una cerca en un valor enter més ràpid que un VARCHAR. Totes les claus del negoci discuteixo en el meu magatzem de dades com camps VARCHAR, sovint una combinació de dos camps. Això és per evitar errors en el futur si tal punt de decisió d'afegir un producte: Vista prèvia:
- DimElement: codi de l'empresa + codi d'elements
- DimUitvoerCode: codi de l'empresa + codi executable
Podem triar la font clau en la dimensió directament relacionats i com un camp per emmagatzemar, per exemple, 100_101 (codi de la companyia, el codi de component). No podem fer operacions de recerca i la paraula als dos camps. La meva preferència és per a compilar aquests dos camps, seguit d'un guió així que la clau es pot seguir des de la font.
Una possibilitat addicional és una suma de comprovació / hash generen els dos camps més. L'avantatge és que una recerca es realitza en un sol camp i el nom d'aquest recurs clau és genèric. Tots els recursos que anomenem exemple clau de la Font Hash sempre és el mateix tipus i longitud.
T-SQL funció de control dels Estats Units Armada SSIS
Checksum és un camp sencer de 4 bytes i per tant no hi pot haver una recerca ràpida de fer. Suma de comprovació no és bo tenir algunes columnes generar una suma de comprovació ja duplicats es pot produir (provat). Generació d'una suma de comprovació a la businesskey no és fiable.
Si puc generar un CRC32 en les tres columnes que conformen la clau del negoci tinc moltes sumes de comprovació de duplicats (per exemple, una taula d'un programa de comptabilitat).
SELECCIONAR A, COUNT (*) Nombre d'AS
DES
(SELECT BINARY_CHECKSUM (cmpcode, doccode, DocNum) com A
DES dbo.oas_dochead_REG com DH
) AS X
Grup per un
TENINT EN COMPTE (*)> 1
Components SSIS
http://www.sqlis.com/post/Checksum-Transformation.aspx
La suma de comprovació SSIS component de la comunitat dóna suport als diferents tipus de sumes de comprovació.
CRC32
Un és el CRC32. He provat això només crea duplicats, i per tant no és fiable. Això passa tant en la generació d'una suma de comprovació sobre una columna de diverses columnes.
Frameworkchecksum
La tècnica frameworkchecksum crea duplicats. Ho he provat amb 200.000 registres, i hi va haver dos duplicats generats.
Original
L'últim missatge també es posarà a prova durant vuit sumes de comprovació de duplicats i no és adequat.
Conclusió
la funció hash MD5 del camp de T-SQL que jo faria servir, és només al voltant del 50% més lent perquè és un camp VARCHAR. La suma és un camp sencer. En aquest cas, podria també fer una recerca a la font principal, que és encara menor.
Actualització:
En el nostre magatzem s'utilitza un sistema binari (20) en el camp com dimensions LookupHash. L'avantatge és que no és un nom genèric es crea per la tecla d'origen. Hi per obtenir surrogatkey poblar el fet que ara pot fer en el camp LookupHash. Un altre avantatge és que una indexació de camp binari és bo.
En resum: en crear la seva dimensió sempre generarà una columna LookupHash de tipus binari (20). Següent fer a la clau de combinació del fet de convertir també a la mateixa binària (20) en les mateixes columnes, el resultat és el mateix que en la dimensió. A continuació, poden obtenir ràpidament surrogatkey!
Etiquetes 
