Re: Guidelines to a decent support of surrogate key implementation

"Cimode" <cimode_at_hotmail.com> wrote in message news:1180006800.249133.57930_at_q69g2000hsb.googlegroups.com...
> 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'm relieved.

> 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.
>

I think that an internal row address identifies and locates a particular row (the container). I think that a surrogate key identifies (by content) the data in a particular row. I don't think the two ideas are substitutes for each other, in a context where these two are visible.

In a context where the two are transparent, I don't see why the phrase "surrogate keys" needs to be used at all.

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

I also want to see several points of view... Received on Thu May 24 2007 - 14:33:40 CEST