Re: Surrogate primary key plus unique constraint vs. natural primary key: data integrity?

On 13 mar, 10:51, Roy Hann <specia..._at_processed.almost.meat> wrote:
> Cimode wrote:
> >> > But the point is that subjectivity can not be taken from
> >> > the equation in any scheme involving establishing a unique identifier.
>
> >> I think you have abbreviated this argument excessively.  I really don't
> >> see your point.
> > I believe the hidden point of the thread was about what would give the
> > impression that there is such thing as a natural or primary key since
> > there is not.
>
> > I rephrase my take on that :
>
> > 1> Any key is at some point in time a surrogate key .  There is no
> > such thing as a natural key.
>
> You are giving excessive weight to the formal logic and no weight at all
> the *application" of formal logic.
Interesting. The former determines the latter.

> Sure it's all just symbols and there
> is no truth either, only valid derivations.  But I want to *apply*
> logic and set theory to database management. If you reject natural keys
> you cannot be talking about databases.  That's not to say your point is
> wrong; just that it is literally useless.
Clarifying the process of natural key generation neither equates to rejecting them nor does it say anything about their usefulness in database design.

I wish I had your confidence.

> > 2> A design effort  to represent a segment of reality is bound to
> > designer's subjectivity.  (Designers are not machines).
>
> Whole-heartedly agreed.  Nor are the user/customers who commission the
> designers.
>
> > 3> Tuple distinguishibility is a part of the design effort, involving
> > upgrade of surrogate to natural key.
>
> Now you're starting to make some sense, but we are way past needing
> to be persuaded that formal logic underlies what we do when we design a
> database.

> > 1 + 2 + 3 implies designer's own subjectivity partly explains the
> > impression  hat there would be such thing as a primary key.
>
> Nah, you've lost me again.
Perhaps that is because, I only view primary key as a design milestone that is no more or less important than the rest of the process.

> >> > Explaining distinguishibility seems a more important challenge
>
> >> Another cryptic squib.  What is challenging about it?
> > Explaining distinguishibility of tuples vs distinguishibility of
> > physical rows is a challenge to most developers since most of them
> > confuse Logical/Physical Layers.  .
>
> More sense.

> Really, you need to show your work.  It's a good thing I am willing to
> press for explanations of your gnomic utterances.
Please allow me to take some burden off your shoulders. Please ignore my useless comments.

"Lie is not the main enemy of Truth, Certainty is" (Nietzche)

> Roy

Regards Received on Wed Mar 13 2013 - 12:20:56 CET