Pro aktualizaci rozměr / skutečnost mus ověřit, zda zznam existuje. To se obvykle provd při pohledu na klčov obchodn (přrodn klč) v rozměru. Pokud tomu tak nen nalezen, je to nov rekord, a to by mělo bt vy-vloit. Pokud je to nael a změnil zznam by měl bt aktualizovn (typ 1), nebo by měl nov rekord m bt vytvořena (typ 2). Jsem to, co expirementeren bylo prvě provd vyhledvn urychlit. Tady moje poznatky tak daleko.
Do vyhledvn na celočselnou hodnotu rychleji ne varchar. Vechny obchodn klče budu zabvat ve svm datovm skladu jako VARCHAR pole, často kombinaci dvou oborů. To je vyvarovat se chyb v budoucnu, pokud takov rozhodnut bod přidat produktu: Preview:
- DimElement: kd společnosti + element kd
- DimUitvoerCode: kd společnosti + spustiteln kd
Můeme zvolit zdroj klč v rozměru přmo souvisej a jsou jako pole pro ukldn, napřklad 100_101 (kd společnosti, součst kdu). Nemůeme dělat vyhledvn a voln o těchto dvou oblastech. Moje preference je sestavit těchto dvou oblastech, nsleduje podtrtko, take klč lze sledovat od zdroje.
Dal monost je kontroln součet / hash vygenerovat dvě pole nad. Vhodou je, e vyhledvn se provd pouze na jednom oboru a pojmenovn tohoto klčovho zdroje je obecn. Kad zdroj nazvme dobrm přkladem toho, vdy Source Hash je stejnho typu a dlky.
T-SQL funkce kontroln SSIS U. S. Navy
Kontroln součet je 4-byte integer pole, a proto tam můe bt rychlm vyhledvnm je třeba udělat. Kontroln součet nen dobr mt někter sloupce generovat kontroln součet, protoe duplicitn se mohou vyskytnout (prokazateln). Generovn kontroln součet na businesskey nen spolehliv.
Mm-li generovat CRC32 na tři sloupce, kter tvoř obchodn klč mm duplicitn mnoho kontrolnch součtů (např. tabulky z četnho programu).
SELECT, COUNT (*) jako čslo
Z
(SELECT BINARY_CHECKSUM (cmpcode, doccode, DocNum) jako
Z dbo.oas_dochead_REG jako DH
) AS X
GROUP BY
S COUNT (*)> 1
SSIS komponent
http://www.sqlis.com/post/Checksum-Transformation.aspx
Kontroln SSIS komponent ze Společenstv podporuje různ druhy kontrolnch součtů.
CRC32
Jednm z nich je CRC32. Testoval jsem to pouze vytvř duplicity, a proto nen spolehliv. To se vyskytuje jak v generovn kontrolnho součtu přes sloupce do vce sloupců.
Frameworkchecksum
Frameworkchecksum technika vytvř duplikty. Testoval jsem to s 200.000 zznamů a byly tam dva duplikty generovny.
Původn
Posledn přspěvek bude tak test pro osm duplicitn kontrolnch součtů a nen vhodn.
Zvěr
MD5 hash funkci od T-SQL Samozřejmě bych pouil, je to jen cca 50% pomalej, protoe je varchar pole. Kontroln součet je čslo pole. V tom přpadě bych mohl tak udělat vyhledvn na zdroj klč, je jetě men.
Update:
V naem skladu pouvme binrn (20) v ternu jako LookupHash rozměry. Vhodou je, e je obecn nzev je vytvořen pro zdroj klč. Vyhledvn zskat surrogatkey naplněn skutečnosti si nyn můete udělat na hřiti LookupHash. Dal vhodou je, e binrn pole indexovn je dobr.
Ve zkratce: při vytvřen svho rozměr bude vdy generovat LookupHash sloupce typu binrn (20). Dal se v JOIN klč od skutečnosti tak převst na stejn binrn (20) na stejnch sloupcch, vsledek je stejn jako v dimenzi. Pak se můete rychle zskat surrogatkey!
Tagy 
