Re: Generalised approach to storing address details

From: Neo <neo55592_at_hotmail.com>
Date: 12 Dec 2006 18:11:22 -0800
Message-ID: <1165975882.389022.123970_at_j72g2000cwa.googlegroups.com>


> > T_Hierarchy
> > Parent Child
> > john jim
>
> ... the bare three lines above imply no such thing.

Ok, let us start by saying we want to represent the fact that John's child is Jim and that Jim's parent is John. We also want to allow a person to have 0 to many parents and 0 to many children. The design that most persons are likely to propose is that shown above. In above table, the information the user thinks he has represented cannot be retrieved by the db engine. The db engine only knows that tuple1's parent is john and tuple1's child is jim. An yes the db engine actually knows this in the same sense that you and I know it. One way to verify this is simply to ask and verify its response. But the db engine does not know that the value of one attribute has a relationship with the value of another attribute. Only the user knows this in above case. For the db to know such implied relationships, the data needs to be restructured, possibly as shown below.

T_PersonAttrib1
pID Name
1 john
2 jim

T_PersonAttrib2
pID childID
1 2

T_PersonAttrib3
pID childID
2 1

> What I've been puzzling about is whether there is a way to declare two
> relations that are somehow equivalent, eg., somehow equatable by engine ...

Would the above meet your criteria?

> I'm probably cuckoo to wonder about this, for reasons of theory
> in math, logic and philosophy that are beyond me, but there it is.

:) Received on Wed Dec 13 2006 - 03:11:22 CET

Original text of this message