( my apologies to those whom I have inadvertently quoted with attributing the quote ... )
Use of surrogate keys versus natural keys is a recurring debate in the world of database design. There are advocates on both sides that are fanatically religious in their preference. Personally, I've tried both ways (for several years each), and my preference has switched multiple times. I've read many people's opinions and they've not been definitively convincing.
As far as I can see, surrogate keys have four major advantages.
First, you can change the natural key, if you wish.
The second advantage is that surrogate keys often take less space in the database than natural keys do.
The third advantage is that one surrogate key can take the place of a multi-field (composite) natural key.
The last advantage is that surrogate keys generally take less thought when designing the database. ( I wish this were not the case. But, in almost all the database design sessions in which I have participated, if surrogate keys were chosen, it has been true. It was chosen because it seemed "easier".)
On the flip-side, though, I've found that the use of surrogate keys typically requires significantly more joins in order to retrieve meaningful information.
Another problem with surrogate keys is that a natural key might be duplicated (although avoiding duplicate natural keys is relatively easily by assigning a unique constraint to the natural key).
( see: http://www.bcarter.com/intsurr1.htm
So, without starting a religious flame war, can you tell me which one you use and why? What situations would naturally lend itself to one way or the other?