Ochen chasto v moei praktike "klyuchi prilozheniya" ne yavlyayutsya optimalnimi - razmer klyuchei, case sensitive etc.

V DWH, osobenno v tablice faktov, klyuchevie polya zhelateno imet kak mozhno uzhe, naprimer vmesto char(9), kotorii realno na praktike zapolnen tolko ziframi, berem int(4) i t.p.

Vtoroi sluchai, kogda u vas DWH napolnyaetsya s neskolkih OLTP, v etom sluchae chtobi "skrestit ezha i uzha" vam ot surrogatnih klyuchei nikuda ne detsya.

V dogonku...


Tema surrogatnih klyucei yavlyaetsya ochen skolzkoi i dazhe v forumah tipa
comp.database.* ili microsoft.public.sqlserver.* vi ne naidete odnoznachnogo otveta na etu temu, skoree 1000 za i 1000 protiv. Eto skoree "religioznii" vopros: surrogatnii ili naturalnii

Lichnaya priverzhenost - surrogatnie klyuchi
+ Maschtabiruemost (podklyuchenie raznorodbnih OLTP)
+ Proizvoditelnost
+ Menshe gemmoroya v OLAP, unifikaciya tipov klyucheiv v OLAP i DWH.

- ETL poluchetsya zamorochennee

Posemu na melkih proektah ne stoit, no... kto znaet kogda melkii pererastet v bolshoi, vot togda i pridetsya "menyat konei na pereprave". Ya kak raz cherez eto proshel. :-)

Samoe gemmoroinoe - ob'yasnit nachalstvu - zachem esche 2 dopolnitelnie cheloveko-nedeli v proekt.

AbdullaНеправильно полагаться в таком вопросе на форум :)
Суррогатные ключи нужны прежде всего для поддержки SCD - slowly changing dims.

nu ne "prezhde vsego", a kak odin iz neskolkih sposobov podderzhki SCD.
tak chto za bi ne stall otdavat SCD pervoe mesto. Odnih surrogatnih klzuchei dlza SCD ne vsegda dostatochno, chtobi poluchit "krasivii rezultat", takoi "chob nachalsvo ponimalo".