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:

Are you saying it is not modeling because I did not show the logical steps I took to arrive at this or is it that modeling with a function is necessarily not a model or what? I didn't search for a UML to text conversion utility ;-) but I could show this as an object that is a function, has methods, etc. What would it take for this to be accepted as a model? --dawn

>
> 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.
Received on Wed Jan 14 2004 - 18:42:48 CET