From: Eric Isaacs on
Tony,

I just read over your article. It's a great article. I did find it
interesting that Codd and Date seemed to disagree on whether surrogate
keys should be exposed to the users.

Date says, "Surrogates must not be concealed from the user because of
the Information Principal." where he's referring to Codd's
Information Principle.

Codd says, "Database users may cause the system to generate or delete
a surrogate, but they have no control over its value, nor is its value
ever displayed to them."

My feeling is that it's okay to expose a surrogate key if there is no
other candidate key to expose, but in doing so you risk the chance
that it will be required to change in the future. But in that case,
you would just create a new candidate field and maintain your
surrogate key separate from your new candidate key and expose that new
field to the users instead of the surrogate key.

-Eric Isaacs
From: Erland Sommarskog on
Tony Rogerson (tonyrogerson(a)torver.net) writes:
> Totally agree - the scope of the surrogate key visibility is with the
> plumbing of the system - so the developers writing the apps can use it
> (but don't see it).
>
> Users never see it at all.

Oh, if it always was that well! In the system I work with, surrogate
keys are often exposed, because developers don't know better.

Recently, I reviewed a change specificiation, which said that in an
certain functon, the surrogate id should be displayed, because the
user for reason needed to know this. (It had something to do with
integration with another system that the customer has.)


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

From: Eric Isaacs on
> Recently, I reviewed a change specificiation, which said that in an
> certain functon, the surrogate id should be displayed, because the
> user for reason needed to know this. (It had something to do with
> integration with another system that the customer has.)

Yes, if it's for integration with other systems, that's when another
candidate key or a GUID should be used instead of a surrogate (INT
IDENTITY) primary key. The GUID can be displayed or used for
reference, though it's not very user friendly. I would still opt to
keep the primary key as the INT IDENTITY column even if a GUID was
also used as a candidate key.

-Eric Isaacs
From: Tony Rogerson on
Its no longer a surrogate and its artificial in that case.

If we start exposing them to the business then they attract changeability
because of business merging etc... and that breaks the rules and purpose of
surrogate keys.

Semantics I know but its important.

Tony.

"Erland Sommarskog" <esquel(a)sommarskog.se> wrote in message
news:Xns9DB6F29027C93Yazorman(a)127.0.0.1...
> Tony Rogerson (tonyrogerson(a)torver.net) writes:
>> Totally agree - the scope of the surrogate key visibility is with the
>> plumbing of the system - so the developers writing the apps can use it
>> (but don't see it).
>>
>> Users never see it at all.
>
> Oh, if it always was that well! In the system I work with, surrogate
> keys are often exposed, because developers don't know better.
>
> Recently, I reviewed a change specificiation, which said that in an
> certain functon, the surrogate id should be displayed, because the
> user for reason needed to know this. (It had something to do with
> integration with another system that the customer has.)
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se
>
> Links for SQL Server Books Online:
> SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
> SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
> SQL 2000:
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>
From: Eric Isaacs on
I suppose that's like using a surrogate mother; if you tell anyone
you're using one and who it is, everyone will know it's actually
artificial.

-Eric Isaacs