I consider myself generally pro-natural, but ultimately agnostic: whatever works best. But some of the synthetic/surrogate guys take it very religiously indeed!

Regards
HJR

perhaps it would be clearer if I split that into a two paragraphs – it’s my work that needs review … ;-)

Perhaps the biggest negative to date as a surrogate number key is that it makes date range partitioning schemes less intuitive (and if you go too far and disassociate date order from surrogate key order… just don’t go there).

Natural keys, surrogate keys, whatever the important thing is to keep the fact ‘normalised’ – just the measures and foreign keys to the dimensions.

I’ve see systems that assign a number to a state code to look up the state code to get to the state name (and so on)
Of the systems I manage for various customers, the one I hate most is an ODS/data switch/data entry system (it’s not a data warehouse – so why me?) It was developed about 8 years ago in a ‘new’ 4GL OO language – it took about 12 months to write (as an aside, I needed to change some functionality so I got one of my team to re-write it in Java – it took less than a week, the original team took 3 months!) . The designers went to great lengths to apply OO design principles – even to creating a single generic database table to hold all of the reference data – four columns: surrogate key, type of data (as a numeric code) “code” (visible to users) and a description – Yuk is a great word for it.

I’ve see systems that assign a number to a state code to look up the state code to get to the state name (and so on)

If they had their way, every fact table would be a bunch of numbers, it would be a mess.

I don’t like turning the date into a number – but offered that up as a counter point (that I was not totally clued into until I read it).

Seems sometimes it makes sense to surrogate them, sometimes it does not (it all comes back to how you use them)