However, a surrogate key might be an intelligent key. An example is an invoice number. An invoice number is an example of a key that (by law) should be absolutely static. There is little reason not to use an invoiceno as a key, as it is absolutely static by definition. Also note that the meaning of the key originates from the computer system, and not the outside world, even if it has created a meaning there.
>
>Another misconception is that surrogate keys should always be invisible for the user. A mutation, or payment might have a key that is generated within the computer system, but is visible in the GUI to be able to use that for pusposes outside of the system. (e.g a reference number in correspondence with customers). I've worked with Navision a decade and a half ago (now a Microsoft product) in which this practise is common).
>
>
>Personally, I use integer keys only as it simplifies audit trails and other metadata throughout the database.


Good point. I've seen places that wind up using a generated surrogate key "as" an intelligent key - sometimes when they just didn't have an intelligent business key to begin with. Yes, by law it should be 100% static.

So yes, sometimes surrogate keys get exposed to users.

I use integer keys the proverbial 99% of the time, for the same reasons you just described, unless there's some compelling reason not to.