Re: Stored fields ordered left to right

"Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message news:slrnc09prd.2rt.adrian_at_sixfingeredman.net...
> Dawn M. Wolthuis <dwolt_at_tincat-group.com> schrieb:
> > So, where I have seen no instances that cannot be modeled equally well
> > with functions as with relations, I have seen many times when a
> > flexible function is a much better way to model the propositions.
> >
> > Take some example propositions:
> >
> > Hope has a cat named Geneva and a dog named Rugby.
> > Shanna has no pets, but did have a dog named Monte who died in 2002.
> >
> > Given only these statements, I might immediately come up with something
like
> > this:
> >
> > a function named PEOPLE and the assignment of an arbitrary (or
sequentially
> > assigned) id for each person
> > PEOPLE("12345") = { "Hope", { ("cat", "Geneva", NULL) , ("dog", "Rugby",
> > NULL)} }
> > PEOPLE("12346") = ( "Shanna", { ("dog", "Monte", "2002") } }
>
> This is not modeling, because all you've done is associate some lists
> with each person, without any formal way to reason about what the lists
> MEAN. I could just as well "model" the first proposition as:
>
> CATS("Geneva") = { {("owner", "Hope")} } etc.
> or even
> PEOPLE("12345") = { "has a cat named Geneva and a dog named Rugby" }
>
> Any extra flexibility you get is by delegating more of the
> semantics/interpretation to the clients of the database.

Since the "lists" are unnamed, one wonders how one does anything with them. I see no flexibility in Dawn's idiocy. Pick lacks flexibility. It is a chained straightjacket with an anchor attached. Received on Thu Jan 15 2004 - 03:09:53 CET