Re: A pk is *both* a physical and a logical object.

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 26 Jul 2007 16:16:28 GMT
Message-ID: <wN3qi.8101$fJ5.4546@pd7urf1no>

JOG wrote:
> On Jul 26, 1:47 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
>

>>"JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>>news:1185445415.561100.98380_at_o61g2000hsh.googlegroups.com...
>>
>>
>>>Just as another example of what i'm on about with this construct
>>>m'larkey: Imagine the library has two copies of "harry potter and the
>>>deathly hallows". Are they the same book?
>>
>>This sounds like "the cat food problem" to me. Is it?

>
>
>
> Well I think the cat-food problem was specifically about duplicate
> propositions, but yes some of the mistakes in its argumentation are
> related. Not understanding that cans may be recorded individually /or/
> as a whole (depending on what a situation requires) could well be
> another symptom of not thinking in terms of "constructs". I think it
> also might have a lot of other consequences, reaching from why hidden
> OID's are a mistake (we need to be able to identify constructs outside
> in the real world), right through to philosopophical mumbo-jumbo like
> why the "theseus ship paradox" isn't a paradox at all (where different
> people just applying different constructs as in the book example).
>
> I certainly think good db admins often recognize all these things by
> intuition, and experience in designing databases and thats who i've
> picked it up from - but (to my knowledge) it has never been formalized
> at the conceptual level. Oh, and apologies for the wanton use of the
> word "construct". I just don't have a better term.
>

I can't fault you for preferring a vague term like "construct". Anybody who ventures into the airy-fairy world of conceptual modelling needs their own private armour. I suspect that some conceptual modellers would probably like it, anything to increase the vocabulary and prolong   the picture-drawing.

I took your use of the word as an expedient, perpaps polite, way to avoid talking about relations when discussing various malarkey that modellers like to to on about while they ignore the application at hand.   (Example of malarkey - talking about relationships, boxes and arrows, without talking about values when they know darned well that the implementation will use a so-called relational dbms.)

On the other hand, I don't see why elementary-school children couldn't be encouraged to think of the relation "construct" and make their own databases before they learn a programming language. One doesn't have to read Leibniz to see the gist of what he meant when he wrote about identity.

p Received on Thu Jul 26 2007 - 11:16:28 CDT