Re: Surrogate Keys: an Implementation Issue
From: Paul Mansour <paul_at_carlislegroup.com>
Date: 20 Jul 2006 10:21:43 -0700
Message-ID: <1153416103.344168.150160_at_m79g2000cwm.googlegroups.com>
Date: 20 Jul 2006 10:21:43 -0700
Message-ID: <1153416103.344168.150160_at_m79g2000cwm.googlegroups.com>
paul c wrote:
> I noticed this in your reply to Bob Badour: "So for most tables it is
> not exposed, but for some it is." I'd say all bets are now off, doesn't
> this put us back where we started, ie. a system-supplied candidate key?
As I said before, it does double duty. If the user requests a auto-incremented surrogate key, it is exposed. If he does not, then it is not exposed. In either case it is used by the DBMS behind the scenes to uniquely identify a row.
> (BTW, as far as "track a row over time" goes, I'd say using real
> time-stamps has fewer problems than auto-increment values for which it
> can be quite hard to avoid duplicates if the incrementing is done by
> user code and the engine multi-tasks