Re: Guidelines to a decent support of surrogate key implementation

On May 24, 12:58 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:1179993531.222375.136310_at_o5g2000hsb.googlegroups.com...
>
> > Lately, I have brought emphasis on the subject of concatenated keys vs
> > addition of column. I have noticed then that the thread quickly
> > turned to a debate about the failure of current dbms's to bring a
> > decent support of surrogate key implementation. From what I observe 3
> > line of thoughts trends appear:
>
> > LINE1> People who think that surrogate key should be an internal
> > physical mechanism to the dbms and invisible to designer who could
> > focus on the logical selection of primary keys
>
> There is something fundamental that I do not understand about LINE1, namely,
>
> In the context of internal physical mechanisms, why is a surrogate key of
> more value than an internal row address?
It is not. I used physical mechanism for consensual communication purposes but I thought internal row adressing when getting physical. I observed that opinions diverge on that perspective.

A common trend is at believing that *familiarity* should be a condition for setting up a surrogate key. Given the subjective nature of *familiarity*, people started demanding control over surrogate keys when it could/should have been automated (at least that's my opinion).

Hope this clarified. I am trying to expose several point of views here to allow people to expose their perspective on that matter.

Regards... Received on Thu May 24 2007 - 13:40:00 CEST