Re: A pk is *both* a physical and a logical object.
Date: Thu, 26 Jul 2007 09:28:16 -0700
On Jul 26, 5:16 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> 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
> >>>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.
Yup, you don't have to necessarily understand the derivation of a theory or design approach to make good practical use of it. Never the easiest read Leibniz.
> p- Hide quoted text -
> - Show quoted text -
Received on Thu Jul 26 2007 - 18:28:16 CEST