Database design - exposing Primary Key

Question

Imagine that I have a Customer table.

And in this table is an ID column, Primary Key int, Identity, all that jazz. Our Customer also has a Name.

Now, if I was to send out information in a report, or an e-mail blast, where there was a link back into my website to uniquely identify that Customer, would it be good practice to use the Primary Key ID field?

All my instincts are telling me this is awful, and that surrogate IDs should PURELY be used for the database only - and never exposed to the outside world in this way.

But I'm looking for that killer argument that I could use in the future, if (when) presented with this case.

Thoughts?

Answer 1

A unique identifier is a unique identifier and if you already have on in the primary key for your database table, use it. Creating another surrogate key would be redundant unless you have GUIDs for example and that was too long for your output format.

--- EDIT ----

Just thinking about the mailing reference, having done this in the past I'd created a table that tracked specific mailings to build metrics around the responses. Each mailing record used a GUID as a primary key to keep it unique and that record linked back to the customer record, no details from the customer record were presented back to the viewer of the link.

If you are presenting customer details then there needs to be access control, even if you obfuscate the ID, anyone getting hold of that link will have access to that data and in most systems that would be unacceptable.

I think the decision starts with 'how secure does this data need to be?' and moves on from there.

Answer 2

I'd suggest not adding a new field, but also don't expose the Id.

Create a table to store emails that you send out. Include a GUID as the primary key and UserId as a foreign key. In the URL you are giving them, link back to the GUID. Then if a user clicks on a URL you can updated the record based on the GUID and indicate when the user accessed the URL.